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Chapter 1: About Advanced Networking 



Volume 6: Advanced Networking discusses networking tasks that are not required in 
every environment, such as: 

□ TCP/IP settings. 

□ WAN Optimization, which enables you to optimize environments with application 
delivery networks (ADNs). 

□ Forwarding, which allows you to define the hosts and groups of hosts to which 
client requests can be redirected. 

□ Health Checks, which reports on the health of upstream hosts. 

About This Book 

This book discusses the following topics: 

□ Chapter 2: "Configuring an Application Delivery Network" on page 11 

□ Chapter 3: "Attack Detection" on page 51 

□ Chapter 4: "Bandwidth Management" on page 57 

□ Chapter 6: "Configuring Failover" on page 87 

□ Chapter 7: "Configuring the Upstream Networking Environment" on page 91 

□ Chapter 8: "Health Checks" on page 119 

□ Chapter 9: "Internet Caching Protocol (ICP) Configuration" on page 127 

□ Chapter 10: "Using RIP" on page 133 

a Chapter 11: "Configuring the SG Appliance as a Session Monitor" on page 139 

□ Chapter 13: "SOCKS Gateway Configuration" on page 183 

□ Chapter 14: "TCP/IP Configuration" on page 191 

□ Chapter 15: "Virtual IP Addresses" on page 195 

□ Chapter 16: "WCCP Settings" on page 197 

□ Appendix A: "Glossary" on page 199 

□ Appendix B: "Using Policy to Manage Forwarding" on page 207 

□ Appendix C: "Using WCCP” on page 211 

Document Conventions 

The following section lists the typographical and Command Line Interface (CLI) syntax 
conventions used in this manual. 

Table 1 -1 . Document Conventions 
Conventions Definition 
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Table 1-1. Document Conventions (Continued) 



Italics 


The first use of a new or Blue Coat-proprietary term. 


Courier font 


Command line text that appears on your administrator workstation. 


Courier Italics 


A command line variable that is to be substituted with a literal name or 
value pertaining to the appropriate facet of your network system. 


Courier Boldface 


A Blue Coat literal to be entered as shown. 


(1 


One of the parameters enclosed within the braces must be supplied 


[] 


An optional parameter or parameters. 


1 


Either the parameter before or after the pipe character can or must be 
selected, but not both. 
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Chapter 2: Configuring an Application Delivery Network 



The Blue Coat implementation of an Application Delivery Network (ADN) requires 
two-sided deployments, with an SG appliance (a peer ) at each end of the WAN link. It 
also features: 

□ Byte caching. The use of byte caching in an application delivery network reduces 
the amount of TCP traffic across a WAN by replacing large chunks of repeated data 
with small tokens representing that data. Working with patterns detected in the 
WAN traffic, the ADN pair of systems handling the traffic builds a byte cache 
dictionary of small tokens. 

□ Acceleration techniques. The use of bandwidth management, compression, 
protocol optimization, and object caching reduces WAN usage even more. 

In such an environment, with only minimal configuration changes, between 30 percent 
and 90 percent of WAN usage can be eliminated, and WAN performance can be 
increased from 30 percent to 90 percent. Applications that benefit from ADN 
optimization include Windows file servers, Web share applications such as WebDAV, 
CRMs such as Siebel, e-mail, and FTP. 




Dictionary Tokens over Encrypted ADN Tunnels 



In addition, you can configure the ADN network to provide additional security to 
internal ADN routing connections and to ADN tunnel connections that carry 
optimized application data. In a fully secured ADN network, only authenticated and 
authorized devices are allowed to join the ADN network. All connections between 
ADN nodes and the ADN manager and connections among the ADN nodes are 
ensured of message authenticity and privacy protection. 
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In this Chapter 

The following topics are discussed in this chapter: 

□ Section A: "About the Blue Coat Implementation for WAN Optimization" on page 13. 

□ Section B: "Basic ADN Setup" on page 19. 

□ Section C: "Transparent and Explicit Connection Deployments" on page 21. 

□ Section D: "Securing the ADN Network" on page 31 . 

□ Section E: "ADN Network History, Statistics, and Health Metrics" on page 38. 

□ Section F: "Advanced Tunnel Optimization" on page 41. 

□ Section G: "Manually Re-Sizing a Byte-Cache Dictionary" on page 44. 

□ Section H: "Related CLI Syntax to Configure an ADN Network" on page 47. 

□ Section I: "Policy" on page 49. 
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Section A: About the Blue Coat Implementation for WAN Optimization 



Section A: About the Blue Coat Implementation for WAN Optimization 

This section provides conceptual information regarding various deployments that employ 
WAN optimization. 

Am ADN network is composed of an ADN manager and backup ADN manager, ADN 
nodes, and a network configuration that matches the environment. 

Blue Coat recommends that you review this section for a high-level overview of the Blue 
Coat ADN implementation. 

This section contains discussions on: 

□ "Components" , below. 

□ "Optimizing the Network" on page 14. 
a "ADN Security" on page 17. 

Components 

The components of the Blue Coat ADN implementation are: 

□ ADN manager and backup ADN manager to provide routing information and control 
access to the ADN network. 

□ ADN nodes in both branch offices and data centers that can be authenticated (identity 
verified) and authorized (permitted to join the network). 

□ (Optional) Am SG Client manager if you have mobile users or users in small branch 
offices, where it might not be cost-justifiable to deploy an acceleration gateway. 

ADN Manager and Backup Manager 

The ADN manager keeps track of and advertises the routes of the appliances it knows 
about. The ADN manager must be one of the peers in the ADN optimization network. 



Note: Peer refers to any ADN system, manager refers to the ADN system that 

broadcasts route information to all ADN peers and controls peer access to the ADN 
network, and node refers to all non-manager ADN peers. ADN managers can also act 
as nodes on the network. 



A backup ADN manager (optional, but recommended) can also be configured. The ADN 
managers and the registered nodes periodically send keep-alive messages to each other. If 
a node detects the primary ADN manager is not responding, the node automatically fails 
over to the back-up ADN manager. The node repeatedly attempts to restore its connection 
with the primary manager. After the primary ADN manager is responding to the node 
again, the active routing connection of this node switches back to the primary manager. 

If the ADN manager detects a node is not responding, the ADN manager removes the 
node from the database and notifies all other nodes in the network to do the same. 

If both the ADN manager and the backup ADN manager are unavailable, no further 
routing advertisements are broadcast. In this case, routes already known by the peers 
continue to be remembered and used. 
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You also can use the ADN manager and backup manager to authorize which peers are 
allowed to advertise or retrieve route information to and from the ADN manager, and 
whether plain connection requests to the ADN manager are accepted. 

Connections to the ADN manager and backup manager are made at startup and kept 
open as long as ADN is enabled. These connections are referred to as routing connections, 
and are used to advertise configured server subnets and to receive routing table updates 
from the ADN manager. 



Note: Even if you use a transparent tunnel deployment where ADN nodes do not 

require routing information, you must configure each ADN node and register it with 
the ADN manager. If you secure the network (highly recommended), the ADN 
manager is used to authorize ADN peers before they join the network. 



Whenever the ADN manager receives a new advertisement from a node that is joining the 
network, a route update is sent to all the appliances in the ADN optimization network 
that have already established a routing connection; in addition, the current routing table is 
updated. The ADN manager and backup manager can each listen on two ports: one 
accepting the default plain (unsecured) routing connection requests and another 
accepting secure routing connection requests. The plain listener can be shut down if 
routing connections from all ADN nodes are secured. 

To configure the ADN manager and backup ADN manager, see Section B: "Basic ADN 
Setup" on page 19. 

ADN Nodes 

An ADN node is any SG appliance that is configured for ADN optimization and sends 
routing information to the ADN manager and backup ADN manager. A node excludes 
those appliances that are acting as ADN managers and backup ADN managers, although 
the manager and backup manager can also participate as nodes in the network. 

SG Client Manager 

The SG Client typically connects to an SG appliance typically located in a data center. That 
SG appliance provides the SG Client software to users, and maintains the software and the 
client configuration on all clients in the ADN network. Only one SG Client Manager can 
be used in the ADN network. 

For information on using the SG Client and SG Manager, see Chapter 12: "Configuring 
and Using the SG Client" on page 145. 



Optimizing the Network 

You must decide on whether the network should use explicit tunnel connections, 
transparent connections, or a combination of both. Note that ADN peers always intercept 
incoming transparent connections if ADN is enabled. 

□ Transparent: The branch SG appliance connects to the original server destination 
address and port. If an upstream proxy is capable of transparent tunneling, the 
downstream proxy transfers data over the ADN tunnel. The destination port is 
preserved and is not affected by security being enabled. Skip to "Transparent 
Connections" for more information. 



14 



Chapter 2: Configuring an Application Delivery Network 



Section A: About the Blue Coat Implementation for WAN Optimization 



□ Explicit: The branch SG appliance connection is established to the ADN peer 
discovered from the routing lookup table. The connection is established to the tunnel 
listening port by default or, if you are preserving the destination port, to the port 
number the application specifies. Skip to "Explicit Connections" on page 16 for more 
information. 

□ Combination: In some circumstances, some ADN nodes can connect transparently, 
while other nodes require explicit routing. Skip to "Combination of Transparent/ 
Explicit Connections" on page 16. 

Transparent Connections 

Transparent connections are used when the network is required to see the original 
destination IP addresses and ports. This requires that each node be configured as an ADN 
node and deployed in in-line mode or virtual in-line mode. 



Note: Beyond setting up an ADN node in an in-line network and configuring the 

ADN node to point to the ADN manager and backup manager, no additional effort is 
required for transparent connections. If you use explicit connections, those 
connections must be explicitly configured. 



Transparent connections take advantage of ADN tunnels that maintain layer-4 
information from the original application connections. Layer-4 information provides an 
administrator more granular control of the ADN network and allows the enforcement of 
network policy. 

In a transparent connection deployment, connections are not established to a particular 
peer in the ADN, as they are in an explicit deployment. An ADN node can establish 
connections to its peers automatically in the absence of any ADN routing information. 

The reject-inbound per interface setting is honored for transparent tunnel interception, 
while the allow-intercept setting is ignored for transparent tunnel interception. 

Internet-bound traffic is automatically accelerated in a transparent deployment if a 
transparent ADN peer is installed at the internet access point and Internet traffic is routed 
correctly. 

Transparent Deployment Load Balancing Scenarios 

In transparent load balancing, routes are not advertised, and configuration of load 
balancing must be done on each node in the ADN cluster. 

If you are using a transparent deployment, you have two options for load balancing. 

□ A dedicated SG appliance as a load balancer; that system makes the decision about 
which node receives which traffic. 

□ A WCCP router or other external load balancer, where the individual nodes in the 
ADN cluster make the informed load balancing decision. 
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Explicit Connections 

Explicit connections are used when maximum network control and granularity is needed. 

Blue Coat supports two explicit connections deployments: explicit or explicit but 
preserving the destination port. In the latter case, the destination port used is the original 
destination port from the client's request, such as port 80 for HTTP. The destination port is 
not affected by the connection setting. 

In both explicit deployments, the server subnets that are fronted by each peer must be 
explicitly configured; the server subnets are then advertised to each ADN node. 

To accelerate Internet traffic in an explicit ADN network, set up a specific ADN peer as the 
Internet gateway. Typically, the Internet gateway is an ADN peer close to the enterprise's 
Internet access point. 



Note: If multiple Internet gateways are available, each peer has its own preferred 

Internet gateway to route all Internet subnets. 



When an ADN peer is configured as an Internet gateway, all other ADN peers forward the 
Internet traffic to this peer. The following logic is used by an ADN peer to determine if the 
connection is destined to the Internet: 

□ If the destination address matches an advertised subnet from any of the ADN peers, 
the connection is forwarded to that peer over the ADN tunnel. 

□ If the destination address matches one of the exempted subnets, the connection is not 
forwarded over the ADN tunnel. 

□ If the destination address does not match an advertised subnet or an exempted 
subnet, the connection is forwarded to an ADN peer that is designated as an Internet 
gateway. 

Explicit Deployment Load Balancing Scenarios 

If you use explicit network connections, you have two options when configuring load 
balancing: 

□ A server subnet, where the branch SG appliance makes the decision about the node 
receiving specific traffic for a destination subnet. This is the easiest and more 
preferred method. For more information, see"Using a Server Subnet" on page 27. 

□ An external load balancer, where that system makes the informed decision about 
which node in the ADN cluster receives specific traffic. For more information, see 
"Using an External Load Balancer" on page 28. 

Combination of Transparent/Explicit Connections 

In some circumstances, it necessary to use explicit connections in addition to the much 
easier and preferred transparent connection deployment. A transparent network that can 
advertise explicit routing connections is supported. This configuration is useful: 

□ When a small branch office is using the SG Client, which allows SGOS functionality 
when a SG appliance is not on site. 

□ If some nodes are not in an in-line configuration or are incapable of initiating 
transparent connections. 
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By default, if an ADN node is advertising routes, explicit connections are made. If no 
explicit routes are found and there is an upstream proxy in the path capable of transparent 
tunneling, the connection is intercepted. This preference is configurable. 

Choosing Which Traffic to Optimize 

When you configure proxy services to manage TCP traffic through the ADN network, you 
can set various attributes that can optimize the traffic for the network. A specific attribute, 
use ADN, allows you to disable ADN for a given service. 

For information on using proxy services, including the services available, refer to Volume 
3: Proxies and Proxy Services. 

ADN Security 

ADN networks can and should be secured. You can limit access by: 

□ Authenticating and authorizing the ADN nodes that are allowed on the network and 
prevent unauthorized nodes from participating. 

□ Securing ADN connections. 

Authenticating and Authorizing ADN Nodes 

By default, authentication and authorization are disabled. 

ADN Node Authentication 

Secure ADN requires an appliance certificate for each ADN peer, including the ADN 
manager and backup manager for identification. You can provide your own device 
appliance certificates or obtain Blue Coat-issued appliance certificates from the Blue Coat 
CA server. For the most secure environment. Blue Coat-issued appliance certificates are 
recommended. 

To enable secure ADN, you must enable the appliance authentication profile for the ADN 
network to use before configuring any other security parameters. 

In secure ADN mode, full mutual authentication can be supported between the ADN 
manager and the ADN nodes and among ADN communicating peers. If authorization is 
enabled on the ADN manager, the peer proxy is authorized through an approval 
mechanism by the ADN manager before joining the network. For more information on 
managing appliance certificates, see Chapter 5: "Authenticating an SG Appliance". 

ADN Node Authorization 

Authorization occurs when the ADN manager gives approval for the device to join the 
network. 

If the profile, authentication, and authorization are configured on each peer, and the 
Pending Peers option is enabled on both the ADN manager and the backup ADN manager 
(if one is configured), the following behavior takes place automatically: 

□ When an ADN node comes up, it contacts the ADN manager for routing information. 

□ The ADN manager extracts the device ID from the connecting ADN node's appliance 
certificate and looks for the device ID in its approved list of ADN nodes. 

• If the device is on the approved list, a request-approved response is sent, 
followed by the route information, and the node joins the network. 
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• If the device is not on the approved list, the ADN manager adds the connecting 
node's device ID to a pending-peers list and sends a request-pending response. 
After the peer is moved to the Approved list by the administrator, a request- 
approved response is sent, followed by the route information, and the node joins 
the network. 

• If the Pending Peers option is not enabled and a peer is not on the approved list, 
the ADN manager sends a request-denied response and closes the connection. 
The connecting node closes the connection and updates its connection status. 

• If a peer is deleted from the approved list, the ADN manager broadcasts a 
REJECT -PEER to all nodes to delete this node and terminate any existing ADN 
connections to it. No new connections are routed through the deleted ADN node. 

For information on configuring authentication and authorization on each ADN node, see 
"Configuring ADN Security Settings" on page 31. 

Securing ADN Connections 

By default, ADN routing and tunnel connection requests are unauthenticated and all 
ADN protocol messaging and compressed application data are transferred in plaintext. 
For maximum security, you can configure the ADN network to secure ADN routing and 
tunnel connections using standard SSL protocol, which provides authentication, message 
privacy, and message authenticity security services, regardless of the application traffic 
that is being accelerated or tunneled. 

In secure ADN mode, you can specify that the ADN manager and tunnel use secure mode 
to listen for routing and tunnel requests. 

When secure ADN is enabled, any existing plain outbound connections are dynamically 
secured by activating SSL according to the secure -outbound setting. 

For information on optimizing and securing ADN tunnels, see Section D: "Securing the 
ADN Network" on page 31 and Section F: "Advanced Tunnel Optimization" on page 41. 
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Section B: Basic ADN Setup 

Basic ADN setup includes: 

□ Configuring each node in an in-line deployment; if you are configuring an explicit 
deployment, you do not need to configure the network in an in-line deployment. 

□ Plugging each node in. 

□ Enabling the ADN manager and backup manager on each node, starting with the 
ADN manager and backup manager themselves. 

If you are using a transparent connection deployment without load balancing, ADN 
configuration is complete at this point. 

If you are using an explicit connection deployment, a transparent connection deployment 
with load balancing, or if you are securing the ADN network (highly recommended), after 
finishing this section you must continue with: 

□ "Explicit Load Balancing" on page 27, for explicit deployment. 

□ "Transparent Load Balancing" on page 22, for transparent deployment. 

□ Section D: "Securing the ADN Network" on page 31 . 

Defining the ADN Manager 

When an SG appliance connects to the primary ADN manager, subnet information is sent 
to the manager, including: 

□ Peer ID: The serial number of the device. This is a globally unique identifier for the 
peer SG appliance that is used as a key to select the dictionary of tokens to use. 

□ Data IP Address and Port: The destination IP address and port number that a branch 
proxy should use when establishing an explicit (non preserve-dest-port) tunnel 
connection. 

□ Server Subnet Advertisements: The list of server subnets the SG appliance contains 
are sent to the ADN manager. 

The first step in configuring an ADN network is to define the primary ADN manager. 
Blue Coat also recommends deploying a backup ADN manager to prevent loss of routing 
information should the primary ADN manager become unavailable for any reason. The 
ADN manager and backup ADN manager must be configured on each peer that is joining 
the ADN network. 

To enable ADN optimization and define the primary/backup ADN managers: 



Note: Fill in all fields on this pane before clicking Apply. 



1. Select Configuration > App. Delivery Network > General. 
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General Device Security j Connection Security 


2 '=* 


0 Enable Application Delivery Network 




- Primary ADN Manager 


3 


" c= '® Self O IP Address: 




Status: ADN connect successful 




- Backup ADN Manager 


A 


Self O IP Address: 




^Status: Not configured 




r Manager Ports 


5 


^ Plain Manager Port: 3034 




Secure Manager Port: 3036 


a 




Reconnect to Managers Refresh Status 



2. Select Enable Application Delivery Network. 

3. Primary ADN Manager: Enter the IP address of the primary ADN manager. This can be 
the SG appliance itself or any peer on the ADN optimization network. 

4. Backup ADN Manager (Optional but highly recommended): Enter the IP address of the 
backup ADN manager or select the Self radio button if this SG appliance is the backup 
manager. 

5. Manager Ports: The ports are set to 3034 (for plain routing connections) and port 3036 
(for secure routing connections). 

6. Click Reconnect to Managers to connect to the ADN manager and backup ADN 
manager, if one is configured. 



Note: You cannot select this option until you select the primary ADN manager and 

apply the changes. The ADN manager does not exist until the changes are applied. 



7. Select Apply to commit the changes to the SG appliance. 
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Section C: Transparent and Explicit Connection Deployments 

If you are configuring a transparent connection deployment without load balancing, 
remember that ADN peers always intercept incoming transparent connections if ADN is 
enabled. No special configuration is required after basic ADN configuration is completed 
unless you use transparent connection load balancing or if you need to configure a 
combined (explicit and transparent) connection network. 

The basic steps for configuring a combined transparent / explicit deployment or a pure 
explicit deployment are: 

□ Connect the nodes in in-line mode or virtual in-line mode only for those nodes that 
are using transparent connections. 

□ (Optional) Secure the ADN network: 

• Configure the ADN nodes for ADN authentication and authorization for 
maximum security (see "Configuring ADN Security Settings" on page 31). The 
settings on each system should be identical. 

• Configure secure tunnels (see Section F: "Advanced Tunnel Optimization" on 
page 41). 

□ (Optional) Configure the load balancing parameters for each node to be used in load 
balancing (see "Explicit Load Balancing" on page 27 or "Transparent Load Balancing" 
on page 22). 

To configure transparent connections, including transparent connection load balancing, 
continue with the next section. 

To configure explicit connections, including explicit connection load balancing, see 
"Configuring an Explicit Deployment" on page 24. 

To configure a combined connection deployment, skip to "Configuring a Combined 
(Transparent and Explicit) Deployment" on page 30 . 

Configuring a Transparent Deployment 

After you have completed basic ADN configuration, transparent connections are made 
automatically. No further configuration is required, unless you need to configure 
transparent load balancing. 



Transparent Deployment Notes 

□ The first proxy in the chain that supports transparent tunnels and is on the same ADN 
network intercepts ADN transparent tunnel connections. 

□ In transparent load balancing, routes are not advertised, and configuration of load 
balancing must be done on each node in the ADN cluster. 

□ Transparent load balancing relies on connection forwarding clusters for proper 
operation. All nodes in an ADN load balancing group must be part of the same 
connection forwarding cluster. 

□ If connection forwarding is not set up correctly, load balancing will fail. For 
information on connection forwarding, see Section D: "TCP Connection Forwarding" 
on page 111. 
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Transparent Load Balancing 

In transparent load balancing, routes are not advertised, and configuration of load 
balancing must be done on each node in the ADN cluster. 

If you are using a transparent deployment, you have two options for load balancing. 

□ A dedicated SG appliance as a load balancer; that system makes the informed 
decision about which node receives which traffic. 

□ A WCCP router or other external load balancer, where the individual nodes in the 
ADN cluster make the informed load balancing decision. 

Using the Blue Coat Appliance as a Load Balancer 

When a Blue Coat appliance is used as the external load balancer, it makes the decisions 
about which traffic is directed to which node. 




Red Arrows = Data Packets/Connections ADN Cluster 

Group 1 



Blue Coat SG Appliance is 
Decision Maker 

To configure transparent load balancing with a dedicated Blue Coat appliance as the 
decision maker: 

□ Deploy the load-balancing SG appliance in-line so that it can transparently intercept 
all traffic. 

□ Enable load balancing on all nodes by going to Configuration > App. Delivery Network > 
Tunneling > Load Balancing, and selecting the Enable Load Balancing checkbox. 
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□ (Optional) Configure each box in the cluster with the same load-balancing group 
name. 

□ On the Blue Coat appliance that's acting as the dedicated load balancer, select Act as 

load balancer only through the Configuration App. Delivery Network >Tunneling > Load 
Balancing tab. 

□ Put all ADN nodes into a connection forwarding cluster. For more information, see 
Section D: "TCP Connection Forwarding" on page 111. 



Note: No special configuration is required for client IP spoofing beyond standard 

configuration, which is to enable reflect-client-ip on the branch SG appliance and to 
set the concentrator SG appliance to allow client-ip spoofing under ADN tunneling. 



Using a WCCP Router or L4 Switch as a Load Balancer 

Using a WCCP router or L4 switch as a transparent load balancer is similar to using an SG 
appliance as a transparent load balancer, except that WCCP router or L4 switch must be 
configured on each system in the cluster. In this scenario, the router or switch cannot 
guarantee ADN peer affinity because the router cannot use the peer ID as input for its 
hash. Because of this, the ADN nodes make the actual informed routing decisions. 



Branch SG Appliance 




WCCP Router 
Group WCCP 1 



Origin Content Server 



ADN Manager 



Legend: 

Black Arrows = ADN Manager Connections 
Red Arrows = Data Packets/Connections 



ADN Cluster 
Group WCCP 1 



Each Node is Decision Maker 
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To configure transparent load balancing with the nodes in the ADN cluster as the decision 
makers: 

□ Enable load balancing on all nodes by going to Configuration > App. Delivery Network > 
Tunneling > Load Balancing, and selecting the Enable Load Balancing checkbox. 

□ (Optional) Set the same group name on all of the nodes in the cluster. 

□ Put all ADN nodes into a forwarding connection cluster. For more information, see 
Section D: "TCP Connection Forwarding" on page 111. 

□ Configure WCCP settings on all nodes. For more information, see Chapter 16: 

"WCCP Settings" on page 197. 

□ Configure WCCP router settings. Review the vendor's documentation for 
information. 



Note: Note: If client IP spoofing is desired, you must configure WCCP so that both 

traffic from the Branch Appliance to the Origin Content Server and traffic from the 
Origin Content Server to the Branch Appliance is redirected through WCCP. This 
requires configuring WCCP on multiple interfaces on your router, or configuring "in/ 
out" rules. If specific ports are desired (rather than all ports), you must configure both 
source-port and destination-port rules in two different service groups. 



Configuring an Explicit Deployment 

Complete the following steps to configure an explicit deployment: 

□ Configure server subnets on each peer and enable an Internet gateway (see 
"Managing Server Subnets and Enabling an Internet Gateway" ). 

□ (Optional) Preserve the destination port (see "Preserving the Destination Port" on 
page 26). 

□ Configure explicit load balancing (see "Explicit Load Balancing" on page 27) 

Managing Server Subnets and Enabling an Internet Gateway 

The server subnets you create here are advertised by this peer upon joining the explicit 
ADN network. You can also enable the peer as an Internet gateway. In addition, subnets 
not intended to go over ADN tunnels or to be routed to Internet gateways can be 
configured as exempt subnets. 



Note: You can also configure the exempt subnet capability through policy that 

allows you to disable ADN tunnel for specific connections. For more information, 
refer to Volume 11: Content Policy Language Guide. 



To create server subnets for this peer: 

1. Select Configuration > App. Delivery Network > Routing. 
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Server Subnets Internet Gateway 

Server Subnets 

Server 5ubnets 



110 . 9 . 59 . 200/32 




3 



2 Add j [ Remove ] ( Clear All 

2. Click Add. 

3. Add the IP/Subnet route to be advertised by the ADN manager; click OK. 

4. (Optional) Repeat for additional routes. 

5. Select Apply to commit the changes to the SG appliance. 

To enable this peer as an Internet gateway: 

1. Select Configuration > App. Delivery Network > Routing > Internet Gateway. 



Added 

Server 

Subnet 
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Server Subnets Internet Gateway | Advanced 

0 Enable this ProxySG as an Internet Gateway for all subnets except the following: < 3 - 



Exempt Subnets 
10 . 0 . 0 . 0/8 

172 . 16 . 0 . 0/12 

192 . 168 . 0 . 0/16 



10 . 9 . 59 . 0/24 




^ ^ [ Add j ( Remove ] [ Clear All ] 

2. Select the Enable this ProxySG as an Internet Gateway for all subnets except the 
following checkbox. 

3. Click Add. 

4. Add the IP / Subnet that must not be routed to Internet gateway(s); click OK. 

5. (Optional) Repeat for additional subnets. 

6. Select Apply to commit the changes to the SG appliance. 

Preserving the Destination Port 

Complete the following procedure. 

To preserve the destination port: 

1. Select Configuration > App. Delivery Network > Tunneling > Connection. 
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Connection | Network | Load Balancing j Proxy Processing 




Plain Tunnel Port: 3035 

Secure Tunnel Port: | 3037 








| | Connect using ADN transparent tunneling when possible 

0 When a route is available, preserve the destination TCP port number when connecting to the ADN peer 



2. Select the checkbox for When a route is available, preserve the destination TCP port 
number when connecting to the ADN peer. 

Explicit Load Balancing 

Of the two explicit load balancing types, server subnet or external load balancer, the 
server subnet is the preferred and easiest to use. While the server subnets must be 
configured, no additional load balancing settings must be made, and the ADN nodes 
explicitly advertise their own IP addresses. 

Using a Server Subnet 

If you use an explicit deployment, or if you just want to load balance traffic destined to a 
specific subnet, configure the subnet as a server subnet on each ADN node within that 
group. 

To forward the connection destined to the load balanced subnet, each ADN node selects 
the preferred node from the list of all peers fronting that subnet. This is done by ranking 
the list of all nodes fronting a given subnet from highest to lowest. The node with the 
highest rank is chosen to route the client traffic for that subnet. 
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ADN Cluster 



Branch SG Appliance is 
Decision Maker 



Using an External Load Balancer 

If you use explicit deployments, you can rely upon an external load-balancer fronting a 
group of ADN nodes. The load balancer is configured to distribute the load among the 
nodes that it fronts using client/ IP address affinity. 

The external load balancer provides more control than the server subnet, but it requires 
more configuration. For example, you must create an external VIP address on the 

Configuration > App. Delivery Network > Tunneling > Load Balancing tab on each system in 
the ADN cluster; the VIP address is explicitly advertised by the ADN manager. 

Both server subnet and external load balancer use a cluster of ADN nodes for load 
balancing. The cluster is formed by ADN nodes that are configured to the same ADN 
manager and are advertising the same server subnets. 
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Red Arrows = Data Packets/Connections ADN Cluster 



External Load Balancer 
is Decision Maker 

Whether you are using server subnets or an external load balancer, you must configure 
server subnets. If you are using an external load balancer, you must also configure the 
external load balancer with a VIP address and put the address in the Load Balancing tab. 
Continue with the next procedures to configure explicit load balancing. 

Explicit Load Balancing Procedures 

If you want to use either the server subnet load balancing deployment or the external load 
balancing deployment, you must configure server subnets. If you are using the external 
load balancing deployment, you must also configure the external load balancer with a VIP 
address. 

To configure server subnets: 

1. Go to Select Configuration > App. Delivery Network > Routing. 

2. Click Add. 

3. Add the IP/Subnet route to be advertised by the ADN manager; click OK. 

4. (Optional) Repeat for additional routes. 

For detailed information about configuring server subnets, see "Managing Server Subnets 
and Enabling an Internet Gateway" on page 24. 
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To configure VIP addresses: 

1. Select Configuration > App. Delivery Network > Tunneling > Load Balancing. 

2. Enter the VIP address of the external load balancer. 



Note: The VIP address is added from the Load Balancing tab of the App Delivery 

Network menu, not the Advanced tab of the Network menu. 



3. Select Apply to commit the changes to the SG appliance. 

The address must be entered on each ADN node in the cluster. 

Configuring a Combined (Transparent and Explicit) Deployment 

If you set up a transparent ADN network with no explicit connections, no additional 
configuration is required for transparent tunnel connections to work unless you want to 
configure load balancing. To configure transparent load balancing, skip to "Setting Device 
Security" on page 31. 

If you set up a combined ADN network with both explicit and transparent connections, 
you must: 

□ Configure the explicit routes you need (see "Managing Server Subnets and Enabling 
an Internet Gateway" on page 24). 

□ Configure the routing preference for each ADN node to tell ADN peers to prefer 
transparent connections (see "To configure the routing preference:" ). The default is to 
always use advertised, explicit, routes. 

□ Set the manager listening mode to Plain read-only mode if SG Clients are in the 
network (see "To configure ADN manager and tunnel listening mode and ports:" on 
page 34. 

□ Configure transparent or explicit load balancing, if necessary. For more information, 
see "Transparent Load Balancing" on page 22 or "Explicit Load Balancing" on page 
27. 

To configure the routing preference: 

1. Select Configuration > App. Delivery Network > Routing > Advanced. 



Server Subnets j Internet Gateway Advanced 

r Routing Preference 

0 Tell ADN peers to always use advertised routes 

O Tell ADN peers to prefer transparent connections over advertised routes 

2. Select the Tell ADN peers to prefer transparent connections over advertised routes radio 
button. 
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Section D: Securing the ADN Network 

Depending on your environment, you might need to secure your ADN network to 

provide the following services: 

□ Host validation: Securing the ADN network allows you to be sure that the ADN peers 
are talking to the right devices and that the peer is authorized to join the ADN 
network. 

□ Privacy: Privacy can be an issue, especially for tunnels that carry application data. 
You can configure the ADN network to secure ADN routing and tunnel connections 
using standard SSL protocol. SSL tunnels provide authentication, message privacy, 
and message authenticity security services, regardless of the application traffic that is 
being accelerated or tunneled. 

□ Message authenticity: Ensure that messages sent over ADN connections are not 
altered. Messages include the route information sent over the routing connections and 
compressed application data sent over the tunnel connections. 

Secure ADN implementation includes: 

□ Device authentication, managed through the device authentication profile. 

□ Securing the device, including device authentication profile selection and device ID- 
based peer authorization. 

□ Securing the connections, both inbound and outbound connection security control. 

□ Configuring the SSL proxy. 



Note: If you only want secure routing connections to the ADN manager, an SSL 

license is not required. Secure tunnel connections for applications such as CIFS, 
MAPI, TCP Tunnel, HTTP, or HTTPS/SSL, are dependent upon an SSL license. 



Configuring ADN Security Settings 

For information on setting device security, continue with the next section. For information 
on setting connection security, continue with "Securing Connections" on page 33. 

Setting Device Security 

For maximum security, configure the ADN network for both device authentication and 
device authorization. Device authentication must be configured first. 



Note: If the device being configured for authentication has Internet access, 

acquisition of the SG appliance certificate is automatic. If you use your own appliance 
certificates and profile, or if the affected device does not have Internet access, manual 
device authentication is required. 



For information on configuring device authentication, see Chapter 5: "Authenticating an 
SG Appliance" on page 77. 

After the device authentication has been set up, point the ADN manager and ADN 
backup manager to the profile that is being used for authentication. Then enable 
authorization for maximum security. 
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Note: You cannot enable device authorization before configuring the ADN manager 

and backup ADN manager. You can, however, configure the ADN manager and 
backup ADN manager and then, without pressing Apply, enable device authorization. 
Then press Apply to save both tabs. 



To set device security: 

1. Select Configuration > App. Delivery Network > General > Device Security. 



2 . 



General 



Device Security 



Connection Security 



2b 




Or 






2c 


E5- 



Device Authentication Profile: | bluecoat-appliance-certificate v 
Extracted Device ID: 4605060001 



r Authorization 



M Validate ADN Peer Device IDs 
Primary Manager Device ID: self 
Backup Manager Device ID: 



Retrieve Manager IDs 



Retrieved Manager IDs 



Primary Manager Device ID: self 
Backup Manager Device ID: 2505060056 



Accept 



Reject 



Configure the Device Security settings: 

a. Device Authentication Profile: From the drop-down list, select the profile that 
you previously associated with the device authentication keyring. Note that 
only devices using the same profile are authenticated. 

b. Extracted Device ID: The device ID that was extracted based on the selected 
profile is automatically displayed. 



Note: The device ID is only used for security. The peer ID is the serial number. 



c. To enable authorization, select the Validate ADN Peer Device IDs checkbox. 

• If the primary or backup ADN manager is Self, the device ID is automatically 
displayed. 

• If the primary or backup ADN manager is a different system, click the 
Retrieve Manager IDs button to see the device ID. Click Accept to add the 
Manager device ID to the Authorization field. 



Note: Authorization of devices is not complete until the devices have been 

approved to be part of the network. For more information on approving devices, see 
"ADN Node Authorization" on page 17. 



3. Select Apply to commit the changes to the SG appliance. 
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Securing Connections 

Use the Connection Security tab to set: 

□ Manager and Tunnel Listening Mode. 

□ Secure Outbound Connections. 

Listening Mode Options 

In secure ADN mode, you can specify that the ADN manager and tunnel use secure mode 
to listen for routing and tunnel requests. By default, ADN routing and tunnel connection 
requests are unauthenticated and all ADN protocol messaging and compressed 
application data are transferred in plain text. 

You must enable the device authentication profile before setting any other security 
parameters. 

After the profile is configured, the following security modes are automatically set: 

□ Secure-outbound: (Secure Proxies) Both outbound routing and secure proxy 
connections are secured. You can also select the radio button to: 

• Not secure ADN connections. 

• Secure only ADN routing connections. 

• Secure all ADN and routing connections. 



Note: The secure-outbound feature is dependent upon an SSL license. 



□ Manager-listening-mode: (Both) Listen for requests on two ports: plain and secure. If 
your deployment requires a different ADN manager listening mode, you must 
explicitly configure it. Other options available are: 

• Secure Only. 

• Plain Only. 

• Plain Read-Only. This mode is recommended if your network uses SG clients. 

□ Tunnel-listening-mode: (Both) Listen for requests on two ports: plain and secure. Other 
options are: 

• Secure Only (Note that tunnel listening mode cannot be set to secure-only if SG 
Clients exist on the ADN network). 

• Plain Only. 

Secure Outbound Connections 

When secure ADN is enabled, any existing plain outbound connections are dynamically 
secured by activating SSL according to the secure -outbound setting. Determine which 
outbound ADN connections are secured by changing the secure -outbound parameter. If 
you select: 

□ None: Neither routing nor tunnel connections are secured. Secure proxy connections 
bypass ADN connections and go directly to the origin content sever. 

□ Routing-only: Only routing connections are secured. Secure proxy connections bypass 
ADN connections and go directly to the origin content sever. 
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□ Secure Proxies: Routing connections and secure proxy connections are secured. 

□ ALL: All outbound connections are secured. 



Note: Securing all outbound ADN connections should be done only if the platform 

has sufficient capacity to handle the extra overhead. 



The table below describes secure outbound behavior with various applications. 



Table 2-1 . Secure Outbound Behavior 



Secure-Outbound 

Setting 


Routing 

Connections 


Application Connections 


CIFS 


SSL Proxy 
Intercept Mode 


SSL Proxy 
Tunnel Mode 


None 


Plain Text 


Plain Text 


Bypass ADN 


Bypass ADN 


Routing-only 


Encrypted 


Plain Text 


Bypass ADN 


Bypass ADN 


Secure Proxies 


Encrypted 


Plain Text 


Encrypted 


Encrypted by application 


All 


Encrypted 


Encrypted 


Encrypted 


Encrypted by application 



To configure ADN manager and tunnel listening mode and ports: 

1. Select Configuration > App. Delivery Network > General > Connection Security. 



2 . 



General 



Device Security 



Connection Security 



|- Manager Listening Mode 

O Secure Only C) Plain Read-Only ® Plain Only Q Bot h 



C Tunneling Listening Mode 

O Secure Only ® Plain Only 0 Both 



r Secure-Outbound Mode 



® Do not secure ADN connections 
O Secure only ADN routing connections 

O Secure ADN routing connections and tunnel connections made by secure proxies 
0 Secure all ADN routing and tunnel connections 



To configure manager listening mode and ports: 

• To change the manager listening mode, go to Configuration > App. Delivery 
Network > General > Connection Security. The default is Plain-only before the 
device authentication profile is selected. After the device authentication profile is 
selected, the manager listening mode switches to Both by default. 

• To change the manager listening ports, go to Configuration > App. Delivery Network 
> General > General. The default is plain port 3034 and secure port 3036. 
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3. To configure tunnel listening mode and ports: 

• To change the tunnel listening mode, go to Configuration > App. Delivery Network > 
General > Connection Security. The default is Plain-only before the device 
authentication profile is selected. After the device authentication profile is 
selected, the manager listening mode switches to Both by default. 

• To change tunnel listening ports, go to Configuration > App. Delivery Network > 

Tunneling > Connection. The default is plain port 3035 and secure port 3037. 

The tunnel listening port is used only if there are explicit tunnel connections to 
this ADN node using the non-preserve-dest-port mode. 

4. Select Apply to commit the changes to the SG appliance. 

Authorizing Devices to Join the Network 

After a node is configured for authentication (device security) and peer validation is 
enabled on the ADN manager, the node must be accepted by the ADN manager and the 
backup ADN manager, if configured, before the device is allowed to join the network 
(authorization) . 

□ When an ADN node comes up, it contacts the ADN manager for routing information. 

□ If secure-outbound is None on the ADN node and the ADN manager's listening mode 
is not secure-only, the ADN node connects to the plain manager listening port and 
immediately joins the ADN network. 

□ If the ADN node connects to the secure manager listening port, the ADN manager 
extracts the device ID from connecting ADN node's appliance certificate and looks for 
the device ID in its approved list of ADN nodes. 

• If the device is on the approved list, a request-approved response is sent, 
followed by the route information, and the node joins the network. 

• If the device is not on the approved list, the ADN manager adds the connecting 
node's device ID to the pending-peers list and sends a request -pending 
response. After the peer is moved to the Approved list by the administrator, a 
request-approved response is sent, followed by the route information, and the 
node joins the network. 

• If the Pending Peers option is not enabled and a peer is not on the approved list, 
the ADN manager sends a request-denied response and closes the connection. 
The connecting node closes the connection and updates its connection status. 

• If a peer is deleted from the approved list, the ADN manager broadcasts a 
REJECT -PEER to all nodes to delete this node and terminate any existing ADN 
connections to it. No new connections are routed through the deleted ADN node. 
To have the denied peer rejoin the ADN network, go to ADN > Config > General > 
Reconnect to Managers. 

To approve a device to join the network: 



Note: Device security must be enabled on all ADN peers you want to join the 

network before you complete this procedure on the ADN manager and backup ADN 
manager. For more information, see "Setting Device Security" on page 31. 
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1. Go to Configuration > App. Delivery Network > Manager > Approved Peers. 

2. To manage peers that you want to be approved to join the network or that have 
previously been approved to join the network: 

• Add peers to the list by selecting Add; a dialog box displays that allows you to 
enter one or a group of peers by listing one to a line. Click OK when through. If 
the device contacts the ADN manager and is on the approved list, a request- 
approved response is sent, followed by the route information, and the node joins 
the network. 

• Remove peers by highlighting the peer or peers and selecting Remove. If a peer is 
deleted from the approved list, the ADN manager broadcasts a reject- peer to 
all nodes to delete this node and terminate any existing ADN connections to it. 
No new connections are routed through the deleted ADN node. 

3. Select Apply to commit the changes to the SG appliance. 

To manage devices not yet approved to join the network: 

If a peer is configured to contact the ADN manager on startup but has not been added to 

the approved list, the ADN manager adds the peer to the list of pending peers if the Allow 

Pending Peers checkbox is selected. The peer moves from the Pending Peers list to the 

Approved Peers list only through human action. 

1. Go to Configuration > App. Delivery Network > Manager > Pending Peers. 



Approved Peers Pending Peers 

0 Allow Pending Peers 

Pending Peers 

Device ID Connecting from Action 



Accept ] ( Reject ] ( Leave Pending ] ( Refresh 
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2. Select the Allow Pending Peers checkbox. 

3. To manage pending peers: 

• Highlight a peer and click Accept or Reject; alternatively, you can select or reject 
all peers in the list by clicking Accept All or Reject All. If accepted, the peer moves 
to the Approved list; if not, it is dropped from the Pending Peers list. 

• You can also leave peers in the pending list by not selecting them or selecting 
them and clicking Leave Pending. 

4. Select Apply to commit the changes to the SG appliance. 

Approved/Pending Notes 

□ Approved lists on the primary and backup ADN managers are not automatically kept 
in sync. You must approve peers on both the primary and backup ADN managers. 
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Section E: ADN Network History, Statistics, and Health Metrics 

After ADN optimization has been enabled and is processing, you can review byte caching 
history and various byte caching statistics. 

Reviewing ADN History 

Review the Traffic Mix and Traffic History tabs in Configuration > Statistics to be sure that 
ADN is working. For more information on Traffic Mix and Traffic History, refer to the 
statistics information in Volume 10: Managing the Blue Coat SG Appliance. 

To review ADN history, select Configuration > Statistics > ADN History. 




Inbound Compression Gain represents traffic received from another peer. Outbound 
Compression Gain represents the traffic sent to other peers. 

The values include both compression and byte-cache gain. 

Reviewing Byte-Caching Statistics 

To review byte caching statistics, select Statistics > Advanced and select the ADN link from 
the list. 

Per connection real time statistics are provided. Each connection has the following details: 

□ Client IP address /port. 

□ Server IP address/port. 

□ Bytes received from the application: The total bytes received from the client/server/ 
application proxy. 
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□ Bytes sent to the application: The total bytes sent to the client /server /application 
proxy. 

□ Bytes received from the peer SG appliance: The bytes received on the ADN tunnel 
connection from the peer at the other end of the WAN link. (This is compressed unless 
byte caching is disabled). 

□ Bytes sent to the peer SG appliance: The bytes sent on the ADN tunnel connection to 
the peer at the other end of the WAN Link. (This is compressed unless byte caching is 
disabled). 

□ Duration: The lifetime of this connection. 

Reviewing ADN Health Metrics 

You can see the state of the ADN network, specifically the ADN node, by checking the 

Statistics > Health > General tab. 

The status can have the values as shown in the following table. The information is meant 

for diagnostic and debugging purposes. 
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Table 2-2. Connectivity to ADN Routing Manager Health Metric 



Status 


Message 


Description 


State 


ADN Health Status 


Connected 


The ADN node is connected to the ADN 
manager, ready to receive any route /peer 
updates. 

If a backup manager exists, this state 
indicates the node is connected to both 
Managers. 


OK 




Functionality 

Disabled 


ADN functionality is not enabled. 


OK 




Not operational 


ADN functionality is not operational yet — 
components are starting up or shutting 
down. 


OK 




Connection 

Approved 


The ADN node has been approved to 
connect to the ADN manager. 


OK 




Connecting 


The ADN node is in process of connecting 
to ADN manager. 


OK 




Partially Connected 


The ADN node is connected to one ADN 
manager but not the other. 


Warning 




Mismatching 
Approval Status 


The ADN node is approved by the current 
active ADN manager but is rejected by the 
backup manager. This warning only exists 
if a backup ADN manager is configured. 


Warning 




Approval Pending 


The ADN node is awaiting a decision from 
the active ADN manager for the node's 
request to join the ADN network. 


Warning 




Disconnected 


The ADN node is not connected to the 
ADN manager and cannot receive route/ 
peer information. 

If a backup manager is configured, this 
state indicates the node is disconnected 
from both manager nodes. 


Critical 




Connection Denied 


The ADN node is rejected by the ADN 
managers in the node's request to join the 
ADN network. 


Critical 


ADN Manager Status 


Not an ADN 
manager 


The ADN node is not an ADN manager. 


OK 




No Approvals 
Pending 


All ADN nodes that are requesting to join 
the network are already on the approved 
list. 


OK 




Approvals Pending 


ADN nodes are requesting to join the 
network. The approvals are made by the 
administrator. 


Warning 
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Section F: Advanced Tunnel Optimization 

Tunnel connections are between the branch and concentrator proxies and are made on 
demand. To reduce connection startup latency, tunnel connections are pooled and reused. 

If a route is present, proxies that support ADN optimization use an ADN tunnel 
connection. Data traveling over the tunnel connection is subject to byte caching, 
compression, and encryption, per the defined policies. 

The tunnel connection occurs independently of the ADN optimization options chosen for 
that connection. These options can be configured for specific services and can also be 
modified in policy. 



Note: Encryption options cannot be set through policy. 



Optimization options include byte caching and gzip compression; byte caching and gzip 
compression can be controlled separately for inbound and outbound traffic on the WAN. 

By default, ADN routing and tunnel connection requests are unauthenticated and all 
ADN protocol messaging and compressed application data are transferred in plaintext. 
For maximum security, you can configure the ADN network to secure ADN routing and 
tunnel connections using standard SSL protocol, which provides authentication, message 
privacy, and message authenticity security services, regardless of the application traffic 
that is being accelerated or tunneled. 

For information on securing the network, see Section D: "Securing the ADN Network" on 
page 31. 



Setting Advanced Tunneling Parameters 

The tunneling parameters you set determine the behavior when you have special 
environmental needs where the default parameters are not adequate. These parameters 
generally do not need to be changed. Parameters that can be changed include: 

□ Connection Settings (see "To configure ADN manager and tunnel listening mode and 
ports:" on page 34). 

□ Network Settings (see "To configure network tunneling settings:" ). 

□ Load Balancing Settings (see "Transparent Load Balancing" on page 22 and "Explicit 
Load Balancing" on page 27). 

□ Proxy Processing Settings (see "To change parameters for proxy processing:" on page 
42). 

To configure network tunneling settings: 

1. Select Configuration > App. Delivery Network > Tunneling > Network. 
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Connection Network | Load Balancing [ Proxy Processing 

- Reflect Client IP 

When an inbound ADN tunnel connection requests Client IP reflection: 

O Reject the request 

0 Allow the request and reflect the client IP 
0 Allow the request but connect using a local IP 



- TCP Settings 

ADN Tunnel TCP Window Size : 655360 



2. Determine the behavior of the concentrator proxy when a branch proxy requests 
client IP reflection (sending the client's IP address instead of the SG appliance IP 
address to the upstream server). 

This setting is based on whether the concentrator was installed in-line. If the 
concentrator proxy is in-line and can do IP reflection, you can allow client IP address 
reflection requests from clients. If not, set this option to either Reject the Request or 
Allow the request but connect using a local IP to accept the requests but ignore the 
client IP address and use a local IP address. 

3. In the TCP Settings panel, enter the TCP window size to be used on ADN 
optimization tunnel connections. This setting only needs to be changed for high 
bandwidth and high delay environments, such as satellite links. The range is between 
8 KB and 4 MB (8192 to 4194304), depending on your bandwidth and the round-trip 
delay. 



Note: If you know the bandwidth and round trip delay, you can compute the 
value to use as, roughly, 2 * bandwidth * delay. For example, if the bandwidth of 
the link is 8 Mbits/sec and the round-trip delay is 0.75 seconds: 

window =2*8 Mbits/sec * 0.75 sec = 12 Mbits = 1.5 Mbytes 

The setting in this example would be 1500000 bytes. This number goes up as either 
bandwidth or delay increases, and goes down as they decrease. 

You can increase the window size based on this calculation but do not decrease the 
window size if the result is less than 64K. 

The window-size setting is a maximum value; the normal TCP/IP behaviors 
adjust downward as necessary. Setting the window size to a lower value might 
result in an artificially low throughput. 



4. Select Apply to commit the changes to the SG appliance. 

To change parameters for proxy processing: 

1. Select Configuration > App. Delivery Network > Tunneling > Proxy Processing. 



Connection | Network | Load Balancing Proxy Processing 






Enable proxy processing for incoming ADN tunnel connections for the following protocol: 

□ http 
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2. (Optional) If the concentrator is required to perform HTTP proxy processing on 

requests arriving over an ADN tunnel, select HTTP. For most deployments, this is not 
needed. All proxy processing always happens at the branch proxy; generally 
speaking, the concentrator proxy just compresses and decompresses bytes and 
forwards them to and from the server. If this setting is enabled, proxy processing 
happens at both the branch and concentrator. 



Note: If you enable this setting, do not duplicate any of the policy that exists at 

the branch, since the branch settings still apply. Depending on the policy 
involved, doing the processing twice can cause problems (such as doing URL 
rewrite multiple times) or it might just be unnecessary, taking up valuable 
resources. 



3. Select Apply to commit the changes to the SG appliance. 
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Section G: Manually Re-Sizing a Byte-Cache Dictionary 

The size of a byte-cache dictionary is dynamically based on the amount of traffic between 
two peers. Generally, the dynamic settings are acceptable; you do not need to change the 
dictionary size. Only if you determine that the algorithm performance does not guarantee 
a sufficient dictionary size for a specific peer should you manually set the dictionary size. 

The byte cache itself, consisting of all data seen on the network, is stored on disk. 
However, byte caching stores index data in RAM. You cannot change the amount of 
memory allocated for a peer, but you can manually set the amount of disk space to be set 
aside. The amount of memory set aside is based on the disk space. 

A table of peer rankings and dictionary sizes is created and maintained by the SG 
appliance. Peers are allocated dictionary space in order starting with the highest ranking 
peer in the table until each peer has been allocated resources, or maximum available 
amount of byte cache memory is reached. 



Note: The rank table can track peers that are using SGOS 5.1.3, but these peers 

cannot dynamically re-size or delete their dictionary. 



After the maximum available resources are reached, any peers that have not been 
allocated a dictionary cannot use byte caching. If those peers have existing dictionaries, 
the tunnels are downgraded to gzip compression only and the existing dictionary is 
deleted. 

A node can re-negotiate a new shared dictionary size with one of its peers, and the 
dictionaries grow or shrink to their new resource levels. The final shared dictionary sizes 
between two peers is the minimum dictionary size that each peer tries to negotiate. To 
guarantee a minimum dictionary size, the value should be set on both peers. (See "To 
manually resize byte cache dictionaries from the Statistics tab:" on page 45.) 

When a peer joins the network, it is added to the peer ranking table. How much dictionary 
space it is allocated depends: 

□ If the maximum amount of resources have already been reached, the new peer can do 
gzip compression only. 

□ If the maximum amount of resources have not been reached: 

• If no history exists for this peer, then the peer negotiates a default dictionary size 
based on its maximum memory and maximum disk space. 

• If history does exist for the peer and the peer's rank guarantees the peer a 
dictionary, the peer is allocated a dictionary based on that history. 

The peer ranking table is persistent across system reboots; the dictionaries themselves are 
re-sized upon any of the following conditions: 

□ System restart. 

□ A full dictionary. 

□ If the dictionary size is set manually. 

The re-ranking allows potentially unused dictionaries to be identified and removed, 
freeing resources. 
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You can manually resize an ADN byte-caching dictionary in two places in the Blue Coat 
appliance Management Console: From the Statistics > ADN History > Peer Dictionary Sizing 

tab, or from the Configuration > ADN > Byte Caching tab. You might find the Statistics tab 
easier to use, since you are not required to know the peer ID. Note, however, that only 
peers that are online are displayed in the Statistics tab. If a peer is offline. Configuration > 
ADN > Byte Caching can be used to configure manual dictionary size for any ADN peer. 

To manually resize byte cache dictionaries from the Statistics tab, continue with the next 
section. To manually resize byte cache dictionaries from the ADN tab, skip to "To 
manually resize byte cache dictionaries from the Configuration > App. Delivery Network 
> Byte Caching tab:" on page 46. 

To manually resize byte cache dictionaries from the Statistics tab: 

1. Select Statistics > ADN History > Peer Dictionary Sizing. 



Peer Dictionary Sizing | Inbound Comp, Gain | Outbound Comp. Gain 

- Byte Cache Effectiveness 

Rank a Peer ID Peer IP Byte Cache Score Peer Traffic (GB/Day) Fill Rate (GB/Day) Recommended Diet Size (GB) Actual Diet Size (GB) 




( E* 1 



2. The Peer Dictionary Sizing tab gives you statistics relevant to the byte cache 

dictionary size of all peers on the network. 

• Rank: The value of a peer's dictionary. Manually-configured peers have a higher 
rank than dynamically-configured peers. 

• Peer ID: The serial number of the device. 

• Peer IP: The IP address of the device. 

• Byte Cache Score: The score of this peer relative to other peers. Score is based on 
the value of the dictionary and is used to determine rank. 

• Peer Traffic (GB/Day): The average amount of pre-byte-cache traffic per day. 

• Fill Rate (GB/Day): The average amount of data put into the dictionary per day 
over the last week. 
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• Recommended Diet Size (GB): The dictionary size the Blue Coat appliance 
recommends, based on the peer traffic over the last week. 

• Actual Diet Size (GB): The actual size of the dictionary. 

Click anywhere on the line of the device whose dictionary you want to re-size. The 
Edit Peer dialog displays. 

3. To select a dictionary size for the device, select the Manual Re-size radio button and 
enter the value you want in megabytes. 

4. Click OK to have the resizing take effect immediately 

To manually resize byte cache dictionaries from the Configuration > App. Delivery 
Network > Byte Caching tab: 

1. Select Configuration > App. Delivery Network > Byte Caching. 




2. Click New. The Enable Manual Dictionary Sizing dialog displays. 

3. Enter the peer ID (serial number) of the device with whom you are sharing a 
dictionary. 

4. Enter the new value in megabytes. 

5. Click OK. The peer is added to the manually configured dictionary sizing list and is 
ranked at the top of the dictionary byte cache table. 

Dynamic dictionary sizing is re-enabled through highlighting the peer and selecting 

Delete. 
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Section H: Related CLI Syntax to Configure an ADN Network 

□ To enter configuration mode: 

SGOS# (conf ig) adn 
SGOS#(config adn) 



Note: For detailed information on using these commands, refer to Volume 12: 

Command Line Reference . 



□ 



The following subcommands are available: 

SGOS# (conf ig adn) {enable | disable} 

SGOS# (config adn) exit 

SGOS# (config adn) byte-cache 

SGOS# (config adn byte-cache) peer-size peer-id { size_in_megabytes / 

auto} 

SGOS# (config adn byte-cache) exit 
SGOS# (config adn byte -cache) view 



SGOS# (config adn) load-balancing 

SGOS# (config adn load-balancing) 
SGOS# (config adn load-balancing) 
SGOS# (config adn load-balancing) 
SGOS# (config adn load-balancing) 
SGOS# (config adn load-balancing) 
disable } 

SGOS# (config adn load-balancing) 
SGOS# (config adn load-balancing) 



{enable [ disable} 
exit 

external -vip IP_address 
group group_name 

load-balance-only {enable | 

no { external -vip | group} 
view 



SGOS# (config adn) manager 

SGOS# (config adn manager) backup -manager {lP_address [ID] | self} 
SGOS# (config adn manager) exit 

SGOS# (config adn manager) no {backup -manager | primary-manager} 

SGOS# (config adn manager) port port_number 

SGOS# (config adn manager) primary-manager {lP_address [ID] | self} 
SGOS# (config adn manager) secure-port secure_port_number 
SGOS# (config adn manager) view [approved-peers | backup -manager- id 
| pending-peers | primary-manager- id] 



SGOS# (config adn manager) approved-peers 



SGOS# (config adn approved-peers) add peer-device-ID 

SGOS# (config adn approved-peers) exit 

SGOS# (config adn approved-peers) remove peer-device-ID 

SGOS# (config adn approved-peers) view 

SGOS# (config adn manager) pending-peers 

SGOS# (config adn pending-peers) {accept | reject} 

SGOS# (config adn pending-peers) {enable | disable} 

SGOS# (config adn pending-peers) exit 
SGOS# (config adn pending-peers) view 
SGOS# (config adn) routing 

SGOS# (config adn routing) exit 

SGOS# (config adn routing) prefer- transparent {enable | disable} 

SGOS# (config adn routing) view 

SGOS# (config adn routing) advertise-internet-gateway 
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SGOS# (config adn routing advertise-internet-gateway) {disable | 
enable} 

SGOS# (config adn routing advertise-internet-gateway) exempt- 
subnet {add { subnet_prefix[/prefix_length ]} clear-all | remove 
{subnet_prefix[/prefix_length]} | view} 

SGOS# (config adn routing advertise-internet-gateway) exit 
SGOS# (config adn routing advertise-internet-gateway) view 



SGOS# (config adn routing) server- subnets 



SGOS# (config adn routing server-subnets) 
prefix length] 

SGOS# (config adn routing server-subnets) 
SGOS# (config adn routing server- subnets ) 
prefix length] 

SGOS# (config adn routing server-subnets) 
SGOS# (config adn routing server-subnets) 



add subnet prefix [/ 

clear-all 

remove subnet_prefix [/ 

exit 

view 



SGOS# (config adn) security 



SGOS# (config adn security) authorization {enable | disable} 

SGOS# (config adn security) device-auth-prof ile profile_name [no- 
authorization] 

SGOS# (config adn security) exit 

SGOS# (config adn security) manager- listening-mode {plain-only | 
plain-read-only | secure-only | both} 

SGOS# (config adn security) no device-auth-prof ile 

SGOS# (config adn security) secure -outbound {none | routing-only | 

secure-proxies | all} 

SGOS# (config adn security) tunnel - listening-mode {plain-only | 
secure-only | both} 

SGOS# (config adn security) view 



SGOS# (config adn) tunnel 



SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
use-local-ip) 

SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 



connect- transparent {enable | disable} 
exit 

preserve-dest-port {enable | disable} 
port port_number 

proxy-processing http {enable | disable} 
reflect-client-ip (deny | allow | 

secure -port secure_port_number 

tcp-window- size window_size 
view 
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Section I: Policy 

The following gestures can be used for WAN optimization from either the VPM or CPL. 



Note: For more information on using the VPM or CPL to configure policy, refer to 

Volume 7: VPM and Advanced Policy or Volume 11: Content Policy Language Guide. 



□ adn . server (yes | no) (Note that this property overrides all other routing and 
intercept decisions made by ADN based on configuration and routing information.) 

□ adn . server . optimize (yes | no) 

□ adn . server . optimize . inbound (yes | no) 

□ adn . server . optimize . outbound (yes | no) 

□ adn . server . optimize . byte-cache (yes | no) 

□ adn . server . optimize . inbound . byte-cache (yes | no) 

□ adn . server . optimize . outbound . byte-cache (yes | no) 

□ adn . server . optimize . compress (yes | no) 

□ adn . server . optimize . inbound . compress (yes | no) 

□ adn . server . optimize . outbound. compress (yes | no) 
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The SGOS software can reduce the effects of distributed denial of service (DDoS) 
attacks and port scanning, two of the most common virus infections. 

A DDoS attack occurs when a pool of machines that have been infected with a DDoS- 
type of virus attack a specific Web site. As the attack progresses, the target host shows 
decreased responsiveness and often stops responding. Legitimate HTTP traffic is 
unable to proceed because the infected system is waiting for a response from the target 
host. 

Port scanning involves viruses attempting to self-propagate to other machines by 
arbitrarily attempting to connect to other hosts on the Internet. If the randomly selected 
host is unavailable or behind a firewall or does not exist, the infected system continues 
to wait for a response, thus denying legitimate HTTP traffic. 

The SG appliance prevents attacks by limiting the number of simultaneous TCP 
connections from each client IP address and either does not respond to connection 
attempts from a client already at this limit or resets the connection. It also limits 
connections to servers known to be overloaded. 

You can configure attack detection for both clients and servers or server groups, such as 
http:/ / www.bluecoat.com. The client attack-detection configuration is used to control the 
behavior of virus-infected machines behind the SG appliance. The server attack- 
detection configuration is used when an administrator knows ahead of time that a 
virus is set to attack a specific host. 

This feature is only available through the CLI. You cannot use the Management 
Console to enable attack detection. 

This section discusses: 

□ "Configuring Attack-Detection Mode for the Client" on page 51 

□ "Configuring Attack-Detection Mode for a Server or Server Group" on page 55 

Configuring Attack-Detection Mode for the Client 

To enter attack-detection mode for the client: 

From the (config) prompt, enter the following commands: 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) client 

The prompt changes to: 

SGOS# (config client) 

Changing Global Settings 

The following defaults are global settings, used if a client does not have specific limits 
set. They do not need to be changed for each IP address/subnet if they already suit 
your environment: 

□ client limits enabled: true 

□ client interval: 20 minutes 
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□ block-action: drop (for each client) 

□ connection-limit: 100 (for each client) 

□ failure-limit: 50 (for each client) 

□ unblock-time: unlimited 

□ warning-limit: 10 (for each client) 

To change the global defaults: 

Remember that enable/ disable limits and interval affect all clients. The values cannot be 
changed for individual clients. Other limits can be modified on a per-client basis. 



Note: If you edit an existing client's limits to a smaller value, the new value only applies 
to new connections to that client. For example, if the old value was 10 simultaneous 
connections and the new value is 5, existing connections above 5 are not dropped. 



SGOS#(config client) 
SGOS#(config client) 
SGOS#(config client) 
SGOS#(config client) 
SGOS#(config client) 



enable-limits | disable-limits 
interval minutes 

block ip_address [ minutes ] | unblock ip_address 

default block-action drop | send-tcp-rst 
default connection- limit 

integer_between_l_and_65535 

SGOS# (config client) default failure-limit integer_between_l_and_500 
SGOS# (config client) default unblock-time minutes_between_10_and_1440 
SGOS# (config client) default warning-limit integer_between_l_and_100 



Table 3-1. Changing Global Defaults 



enable-limits | 
disable -limits 




Toggles between enabled and disabled. The default is disabled. 
This is a global setting and cannot be modified for individual 
clients. 


interval 


integer 


Indicates the amount of time, in multiples of 10 minutes, that 
client activity is monitored. The default is 20. This is a global 
setting and cannot be modified for individual clients. 


block | unblock 


ip_address 
[ minutes ] 


Blocks a specific IP address for the number of minutes listed. If 
the optional minutes argument is omitted, the client is blocked 
until explicitly unblocked. Unblock releases a specific IP address. 


default block- 
action 


drop | send- 
tcp-rst 


Indicates the behavior when clients are at the maximum number 
of connections or exceed the warning limit: drop the connections 
that are over the limit or send TCP RST for connections over the 
limit. The default is drop. This limit can be modified on a per- 
client basis. 


default 

connect ion -limit 


integer 


Indicates the number of simultaneous connections between 1 and 
65535. The default is 100. This limit can be modified on a per- 
client basis. 


default failure- 
limit 


integer 


Indicates the maximum number of failed requests a client is 
allowed before the proxy starts issuing warnings. Default is 50. 
This limit can be modified on a per-client basis. 
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default unblock- 
time 


minutes 


Indicates the amount of time a client is blocked at the network 
level when the client-warning-limit is exceeded. Time must be a 
multiple of 10 minutes, up to a maximum of 1440. By default, the 
client is blocked until explicitly unblocked. This limit can be 
modified on a per-client basis. 


default warning - 
limit 


integer 


Indicates the number of warnings sent to the client before the 
client is blocked at the network level and the administrator is 
notified. The default is 10; the maximum is 100. This limit can be 
modified on a per-client basis. 



To create and edit a client IP address: 



Client attack-detection configuration is used to control the behavior of virus-infected 
machines behind the SG appliance. 



1. Verify the system is in the attack-detection client submode. 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) client 
SGOS# (config client) 

2. Create a client. 

SGOS# (config client) create client ip_address or ip_and_length 



3. Move to edit client submode. 



SGOS# (config client) edit cl ient_ip_addres s 

The prompt changes to: 

SGOS# (config client ip_address) 



4. 



Change the client limits as necessary. 

SGOS# (config client ip_address) 
SGOS# (config client ip_address) 
integer_between_l_and_65535 
SGOS# (config client ip_address) 
integer_between_l_and_65535 
SGOS# (config client ip_address) 
SGOS# (config client ip_address) 
integer_between_l_and_65535 



block-action drop | send-tcp-rst 

connect ion -limit 

failure- limit 

unblock- time minutes 
warning - 1 imi t 



Table 3-2. Changing the Client Limits 



block-action 


drop | send-tcp-rst 


Indicates the behavior when the client is at the maximum 
number of connections: drop the connections that are over the 
limit or send TCP RST for the connection over the limit. The 
default is drop. 


connect ion -limit 


integer 


Indicates the number of simultaneous connections between 1 
and 65535. The default is 100. 


failure-limit 


integer 


Indicates the behavior when the specified client is at the 
maximum number of connections: drop the connections that 
are over the limit or send TCP RST for the connection over the 
limit. The default is 50. 
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unblock-time 


minutes 


Indicates the amount of time a client is locked out at the 
network level when the client-warning-limit is exceeded. Time 
must be a multiple of 10 minutes, up to a maximum of 1440. By 
default, the client is blocked until explicitly unblocked. . 


warning -limit 


integer 


Indicates the number of warnings sent to the client before the 
client is locked out at the network level and the administrator 
is notified. The default is 10; the maximum is 100. 



To view the specified client configuration: 

Enter the following command from the edit client submode: 

SGOS# (config client ip_address) view 
Client limits for 10.25.36.47: 

Client connection limit: 700 

Client failure limit: 50 

Client warning limit: 10 

Blocked client action: Drop 

Client connection unblock time: unlimited 



To view the configuration for all clients: 

1. Exit from the edit client submode: 

SGOS# (config client ip_address) exit 

2. Use the following syntax to view the client configuration: 

view {<Enter> | blocked | connections | statistics} 



To view all settings: 

SGOS# (config client) view <Enter> 

Client limits enabled: true 

Client interval: 20 minutes 



Default 



client limits: 

Client connection limit: 
Client failure limit: 
Client warning limit: 
Blocked client action: 
Client connection unblock 



100 

50 

10 

Drop 

time: unlimited 



Client limits for 10.25.36.47: 

Client connection limit: 700 

Client failure limit: 50 

Client warning limit: 10 

Blocked client action: Drop 

Client connection unblock time: unlimited 



To view the number of simultaneous connections to the SG appliance: 



SGOS# (config 
Client IP 
127 . 0.0.1 
10.9.16 .112 
10.2.11.133 



client) view connections 

Connection Count 
1 
1 



1 
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To view the number of blocked clients: 

SGOS# (config client) view blocked 
Client Unblock time 

10.11.12.13 2004-07-09 22 : 03 : 06+00 : 00UTC 

10.9.44.73 Never 

To view client statistics: 

SGOS# (config client) view statistics 

Client IP Failure Count Warning Count 

10.9.44.72 1 0 

To disable attack-detection mode for all clients: 

SGOS# (config client) disable- limits 

Configuring Attack- Detection Mode for a Server or Server Group 

Server attack-detection configuration is used when an administrator knows ahead of time 
that a virus is set to attack a specific host. 

You can create, edit, or delete a server. A server must be created before it can be edited. 
You can treat the server as an individual host or you can add other servers, creating a 
server group. All servers in the group have the same attack-detection parameters, 
meaning that if any server in the group gets the maximum number of simultaneous 
requests, all servers in the group are blocked. 

You must create a server group before you can make changes to the configuration. 

To create a server or server group: 

1. At the (config) prompt: 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) server 

The prompt changes to: 

SGOS# (config server) 

2. Create the first host in a server group, using the fully qualified domain name: 

SGOS# (config server) create hostname 

To edit a server or server group: 

At the (config server) prompt: 

SGOS# (config server) edit hostname 

The prompt changes to (config server hostname ). 

SGOS# (config server hostname ) {add | remove} hostname 

SGOS# (config server hostname ) request- limit integer_from_l_to_65535 

where: 



hostname 




The name of a previously created server or server group. 
When adding a hostname to the group, the hostname does 
not have to be created. The host that was added when 
creating the group cannot be removed. 


add | remove 


hostname 


Adds or removes a server from this server group. 
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request -limit 


integer 


Indicates the number of simultaneous requests allowed from 






this server or server group. The default is 1000. 



To view the server or server group configuration: 

SGOS# (config server hostname ) view 
Server limits for hostname: 

Request limit: 1500 
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Bandwidth management (BWM) allows you to classify, control, and limit the amount of 
bandwidth used by different classes of network traffic flowing into or out of the SG 
appliance. Network resource sharing (or link sharing) is accomplished by using a 
bandwidth-management hierarchy where multiple traffic classes share available 
bandwidth in a controlled manner. 



Note: The SG appliance does not attempt to reserve any bandwidth on the network 
links that it is attached to or otherwise guarantee that the available bandwidth on the 
network can sustain any of the bandwidth limits which have been configured on it. The 
SG appliance can only shape the various traffic flows passing through it, and prioritize 
some flows over others according to its configuration. 



By managing the bandwidth of specified classes of network traffic, you can accomplish 

the following: 

□ Guarantee that certain traffic classes receive a specified minimum amount of 
available bandwidth. 

□ Limit certain traffic classes to a specified maximum amount of bandwidth. 

□ Prioritize certain traffic classes to determine which classes have priority over 
available bandwidth. 

Bandwidth Management Overview 

To manage the bandwidth of different types of traffic that flow into, out of, or through 

the SG appliance, you must do the following: 

□ Determine how many bandwidth classes you need and how to configure them to 
accomplish your bandwidth management goals. This includes determining the 
structure of one or more bandwidth hierarchies if you want to use priority levels to 
manage bandwidth. 

□ Create and configure bandwidth classes accordingly. 

□ Create policy rules using those bandwidth classes to identify and classify the traffic 
in the SG appliance. 

□ Enable bandwidth management. 

Bandwidth management configuration consists of two areas: 

□ Bandwidth allocation 

This is the process of creating and configuring bandwidth classes and placing them 
into a bandwidth class hierarchy. This process can be done using either the 
Management Console or the CLI. 
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□ Flow classification 

This is the process of classifying traffic flows into bandwidth management classes 
using policy rules. Policy rules can classify flows based on any criteria testable by 
policy You can create policy rules using either the Visual Policy Manager (VPM), 
which is accessible through the Management Console, or by composing Content 
Policy Language (CPL). 



Note: For more information about using VPM to create policy rules, refer to Volume 7: 
VPM and Advanced Policy. For information about composing CPL, refer to Volume 11: 
Content Policy Language Gidde. 



Allocating Bandwidth 

The process of defining bandwidth classes and grouping them into a bandwidth class 
hierarchy is called bandwidth allocation. Bandwidth allocation is based on: 

□ the placement of classes in a hierarchy (the parent/ child relationships). 

□ the priority level of classes in the same hierarchy. 

□ the minimum and / or maximum bandwidth setting of each class. 

For example deployment scenarios, see "Bandwidth Allocation and VPM Examples" on 
page 68. 

Bandwidth Classes 

To define a bandwidth class, you create the class, giving it a name meaningful to the 
purpose for which you are creating it. You can configure the class as you create it or edit it 
later. The available configuration settings are: 

□ Parent: Used to create a bandwidth-management hierarchy. 

□ Minimum Bandwidth: Minimum amount of bandwidth guaranteed for traffic in this 
class. 

□ Maximum Bandwidth: Maximum amount of bandwidth allowed for traffic in this 
class. 

□ Priority: Relative priority level among classes in the same hierarchy. 

Parent Class 

A parent class is a class that has children. When you create or configure a bandwidth class, 
you can specify another class to be its parent (the parent class must already exist). Both 
classes are now part of the same bandwidth-class hierarchy, and so are subject to the 
hierarchy rules (see "Class Flierarchy Rules and Restrictions" on page 60). 

Minimum Bandwidth 

Setting a minimum for a bandwidth class guarantees that class receives at least that 
amount of bandwidth, if the bandwidth is available. If multiple hierarchies are competing 
for the same available bandwidth, or if the available bandwidth is not enough to cover the 
minimum, bandwidth management is not be able to guarantee the minimums defined for 
each class. 
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Note: The SG appliance does not attempt to reserve any bandwidth on the network links 
that it is attached to or otherwise guarantee that the available bandwidth on the network 
can be used to satisfy bandwidth class minimums. The SG appliance can only shape the 
various traffic flows passing through it, and prioritize some flows over others according 
to its configuration. 



Maximum Bandwidth 

Setting a maximum for a bandwidth class puts a limit on how much bandwidth is 
available to that class. It does not matter how much bandwidth is available; a class can 
never receive more bandwidth than its maximum. 

To prevent a bandwidth class from using more than its maximum, the SG appliance inserts 
delays before sending packets associated with that class until the bandwidth used is no 
more than the specified maximum. This results in queues of packets (one per class) 
waiting to be sent. These queues allow the SG appliance to use priority settings to 
determine which packet is sent next. If no maximum bandwidth is set, every packet is sent 
as soon as it arrives, so no queue is built and nothing can be prioritized. 

Unlike minimums and priority levels, the maximum-bandwidth setting can purposely 
slow down traffic. Unused bandwidth can go to waste with the maximum-bandwidth 
setting, while the minimum-bandwidth settings and priority levels always distributes any 
unused bandwidth as long as classes request it. However, priority levels are not 
meaningful without a maximum somewhere in the hierarchy. If a hierarchy has no 
maximums, any class in the hierarchy can request and receive any amount of bandwidth 
regardless of its priority level. 

Priority 

When sharing excess bandwidth with classes in the same hierarchy, the class with the 
highest priority gets the first opportunity to use excess bandwidth. When the high- 
priority class uses all the bandwidth it needs or is allowed, the next class gets to use the 
bandwidth, if any remains. If two classes in the same hierarchy have the same priority, 
then excess bandwidth is shared in proportion to their maximum bandwidth setting. 

Class Hierarchies 

Bandwidth classes can be grouped together to form a class hierarchy. Creating a 
bandwidth class allows you to allocate a certain portion of the available bandwidth to a 
particular type of traffic. Putting that class into a bandwidth-class hierarchy with other 
bandwidth classes allows you to specify the relationship among various bandwidth 
classes for sharing available (unused) bandwidth. 

The way bandwidth classes are grouped into the bandwidth hierarchy determines how 
they share available bandwidth among themselves. You create a hierarchy so that a set of 
traffic classes can share unused bandwidth. The hierarchy starts with a bandwidth class 
you create to be the top-level parent. Then you can create other bandwidth classes to be 
the children of the parent class, and those children can have children of their own. 

To manage the bandwidth for any of these classes, some parent in the hierarchy must have 
a maximum bandwidth setting. The classes below that parent can then be configured with 
minimums and priority levels to determine how unused bandwidth is shared among 
them. If none of the higher level classes have a maximum bandwidth value set, then 
bandwidth flows from the parent to the child classes without limit. In that case, 
minimums and priority levels are meaningless, because all classes get all the bandwidth 
they need at all times. The bandwidth, in other words, is not being managed. 
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Class Hierarchy Rules and Restrictions 

Certain rules and restrictions must be followed to create a valid BWM class hierarchy: 

□ Each traffic flow can only belong to one bandwidth management class. 

You can classify multiple flows into the same bandwidth class, but any given flow is 
always counted as belonging to a single class. If multiple policy rules match a single 
flow and attempt to classify it into multiple bandwidth classes, the last classification 
done by policy applies. 

□ When a flow is classified as belonging to a bandwidth class, all packets belonging to 
that flow are counted against that bandwidth class. 

□ If a minimum bandwidth is configured for a parent class, it must be greater than or 
equal to the sum of the minimum bandwidths of its children. 

□ If a maximum bandwidth is configured for a parent class, it must be greater than or 
equal to the largest maximum bandwidth set on any of its children. It must also be 
greater than the sum of the minimum bandwidths of all of its children. 

□ The minimum bandwidth available to traffic directly classified to a parent class is 
equal to its assigned minimum bandwidth minus the minimum bandwidths of its 
children. For example, if a parent class has a minimum bandwidth of 600 kbps and 
each of its two children have minimums of 300 kbps, the minimum bandwidth 
available to traffic directly classified into the parent class is 0. 

Relationship among Minimum, Maximum, and Priority Values 

Maximum values can be used to manage bandwidth for classes whether or not they are 
placed into a hierarchy. This is not true for minimums and priorities, which can only 
manage bandwidth for classes that are placed into a hierarchy. Additionally, a hierarchy 
must have a maximum configured on a high-level parent class for the minimums and 
priorities to manage bandwidth. 

This is because, without a maximum, bandwidth goes to classes without limit and there is 
no point to setting priorities or minimum guarantees. Bandwidth cannot be managed 
unless a maximum limit is set somewhere in the hierarchy. 

When a hierarchy has a maximum on the top-level parent and minimums, maximums and 
priorities placed on the classes related to that parent, the following conditions apply: 

□ If classes in a hierarchy have minimums, the first thing that happens with available 
bandwidth is that all the minimum requests are satisfied. If the amount requested is 
less than the minimum for any class, it receives the entire amount, and its priority level 
does not matter. 

Even though a minimum is considered to be a guaranteed amount of bandwidth, 
satisfying minimums is dependent on the parent being able to receive its own 
maximum, which is not guaranteed. 

□ When all of the classes in a hierarchy have had their minimums satisfied, any 
additional requests for bandwidth must be obtained. When a class requests more than 
its minimum, it must obtain bandwidth from its parent or one of its siblings. If, 
however, a class requests more than its maximum, that request is denied — no class 
with a specified maximum is ever allowed more than that amount. 

□ If a class does not have a minimum specified, it must obtain all of the bandwidth it 
requests from its parents or siblings, and it cannot receive any bandwidth unless all of 
the minimums specified in the other classes in its hierarchy are satisfied. 
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□ Classes obtain bandwidth from their parents or siblings based on their priority 

levels — the highest priority class gets to obtain what it needs first, until either its entire 
requested bandwidth is satisfied or until it reaches its maximum. After that, the next 
highest priority class gets to obtain bandwidth, and this continues until either all the 
classes have obtained what they can or until the maximum bandwidth available to the 
parent has been reached. The amount available to the parent can sometimes be less 
than its maximum, because the parent must also participate in obtaining bandwidth in 
this way with its own siblings and/or parent if it is not a top-level class. 

Flow Classification 

You can classify flows to BWM classes by writing policy rules that specify the bandwidth 

class that a particular traffic flow belongs to. A typical transaction has four traffic flows: 

1. Client inbound — Traffic flowing into the SG appliance from a client (the entity sending 
a request, such as a client at a remote office linked to the appliance). 

2. Server outbound — Traffic flowing out of the SG appliance to a server. 

3. Server inbound — Traffic flowing back into the SG appliance from a server (the entity 
responding to the request). 

4. Client outbound — Traffic flowing back out of the SG appliance to a client. 

The figure below shows the traffic flows between a client and server through the SG 

appliance. 



• Client Inbound 



Server Outbound 




Client 



Server 



Some types of traffic can flow in all four directions. The following example describes 
different scenarios that you might see with an HTTP request. A client sends a GET to the 
SG appliance (client inbound). The SG appliance then forwards this GET to a server (server 
outbound). The server responds to the SG appliance with the appropriate content (server 
inbound), and then the appliance delivers this content to the client (client outbound). 



Policy allows you to configure different classes for each of the four traffic flows. See 
"Using Policy to Manage Bandwidth" on page 67 for information about classifying traffic 
flows with policy. 



Configuring Bandwidth Allocation 

You can use either the Management Console or the CLI to do the following tasks: 

□ Enable or disable bandwidth management. 

□ Create and configure bandwidth classes. 
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□ Delete bandwidth classes. 

□ View bandwidth management class configurations. 

Note: If you plan to manage the bandwidth of streaming media protocols (Windows 
Media, Real Media, or QuickTime), you might want to use the streaming features instead 
of the bandwidth management features described in this section. For most circumstances. 
Blue Coat recommends that you use the streaming features to control streaming 
bandwidth rather than the bandwidth management features. For information about the 
differences between these two methods, refer to Volume 4: Web Communication Proxies. 



Enabling Bandwidth Management 

The following procedures explain how to enable or disable bandwidth management. 

To enable bandwidth management: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 



Bandwidth Classes 

0 Enable Bandwidth Management 



-Bandwidth Classes 




Bandwidth Class Min(kbps) 


Max(kbps) 



2. Select or deselect Enable Bandwidth Management. 

3. Select Apply to commit the changes to the SG appliance. 



Creating, Editing, and Deleting Bandwidth Classes 

The following procedure details how to create bandwidth management class. 



To create a BWM class: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 



Bandwidth Classes 

[✓j Enable Bandwidth Management 



An existing 
parent class 



2 



-Bandwidth Classes 

Bandwidth Class Min(kbps) Max(kbps) Priority 

4# ParentA unspecified unlimited 7 




3a 

3b 

3c 

3d 

3e 
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2. To create a new BWM class, click New. 

3. Fill in the fields as appropriate: 

a. Class name: Assign a meaningful name for this class. The name can be up to 
64 characters long; spaces are not allowed. 

b. Parent: (Optional) To assign the class as a child of another parent class in the 
bandwidth class hierarchy, select an existing parent class from the drop-down 
list. 

c. Min. Bandwidth: (Optional) Select Min. Bandwidth and enter a minimum 
bandwidth value in the field (kilobits per second (kbps)). The default 
minimum bandwidth setting is unspecified, meaning the class is not 
guaranteed a minimum amount of bandwidth. 

d. Max. Bandwidth: (Optional) Select Max. Bandwidth and enter a maximum 
bandwidth value in the field. The default maximum bandwidth setting is 
unlimited, meaning the class is not limited to a maximum bandwidth value by 
this setting. 

e. Priority: Select a priority level for this class from the Priority drop-down list — 
0 is the lowest priority level and 7 is the highest. The default priority is 0. 

4. Click OK. 

5. Select Apply to commit the changes to the SG appliance. 

rBandwidth Classes — 




Figure 4-1 . A child bandwidth management class added to a parent class. 

After you add a child class to a parent class, the parent class is denoted by a folder icon. 
Double-click the folder to view all of the child classes under that parent. 

To edit a BWM class: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 

2. Highlight the class and click Edit. 

3. Edit the fields as appropriate. 

To delete a BWM class: 



Note: You cannot delete a class that is referenced by another class or by the currently 
installed policy. For instance, you cannot delete a class that is the parent of another class 
or one that is used in an installed policy rule. If you attempt to do so, a message displays 
explaining why this class cannot be deleted. 



1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 

2. Highlight the class to delete and Delete. 

3. Click Yes to delete the class. 

4. Click Apply. 
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Viewing Bandwidth Management Configurations 

You can view the following bandwidth class configurations: 

□ Level in the hierarchy (parent /child relationships) 

□ Priority level 

□ Maximum bandwidth value 

□ Minimum bandwidth value 

To view BWM configuration: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 

On this tab, you can view a class's minimum, maximum and priority value. Top level 
classes are visible — classes with children have a folder icon on the left. 

2. To view the configurations of the child class(es) of a class, double-click the folder icon. 
The child classes become visible. A second double-click closes the folder. 

Related CLI Syntax to Configure Bandwidth Management 

□ To enter configuration mode: 

SGOS# (config) bandwidth-management 

□ The following subcommands are available: 

SGOS# (config bandwidth-management) enable | disable 

SGOS# (config bandwidth-management) create | delete bwm_class 

□ To enter edit mode: 

SGOS# (config bandwidth-management) edit bwm_class 

□ The following subcommands are available: 

SGOS# (config bw-class bwm_class ) min-bandwidth minimum_in_kbps 
SGOS# (config bw-class bwm_class) max-bandwidth maximum_in_kbps 
SGOS# (config bw-class bwm_class ) priority value_from_0_to_7 
bandwidth-management bwm_class) no {min-bandwidth | max -bandwidth} 
SGOS# (config bandwidth-management bwm_class) parent parent_class_name 
-or- 

SGOS# (config bandwidth-management bwm_class) no parent 
SGOS# (config bandwidth-management bwm_class) view 

Bandwidth Management Statistics 

The bandwidth management statistics tabs (Current Class Statistics and Total Class 
Statistics) display the current packet rate and total number of packets served, the current 
bandwidth rate, and the total number of bytes served and packets dropped. 

Current Class Statistics Tab 

The Current Class Statistics tab displays the following information for each bandwidth 
class: 

□ Current Packet Rate: current packets-per-second (pps) value. 

□ Current Bandwidth: current bandwidth in kilobits per second (Kbps). 
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To view current bandwidth management class statistics: 

1. Select Statistics > Bandwidth Management > Current Class Statistics. 

The high level bandwidth classes and their statistics are visible. 



Current Class Statistics Total Class Statistics 



rBandwidth Classes- 



Bandwidth Class 


| Current Packet Rate(pps) | 


Current Bandwidth(kbps) | 


• bridging 


0 


0 


• ftp 


0 


0 


• http 


0 


0 


• im 


D 


0 


~ 1 streaming 


0 


0 


• P2P 


D 


0 


* service-info 


0 


0 


• socks 


0 


0 


* tcp-tunnel 


0 


0 



Help 



2. To view the statistics of child bandwidth classes, double-click the folder icon of the 
parent class. 

The child classes become visible. A second double-click closes the folder. 

Total Class Statistics Tab 

The Total Class Statistics tab displays the following information for each bandwidth class: 

□ Packets: the total number of packets served. 

□ Bytes: the total number of bytes served. 

□ Drops: the total number of packets dropped. 

To view total bandwidth management class statistics: 

1. Select Statistics > Bandwidth Management > Total Class Statistics. 

The high level bandwidth classes and their statistics are visible. 
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| Current Class Statistics Total Class Statistics 

rBandwidth Classes 




Help 

2. To view the statistics of child bandwidth classes, double-click the folder icon of the 
parent class. A second double-click closes the folder. 

Bandwidth Management Statistics in the CLI 

To view bandwidth management statistics: 

1. To view all bandwidth management statistics, enter the following commands at the 
prompt: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) view statistics 

2. To view the BWM statistics for a specific class, enter the following command at the 
(config) command prompt: 

SGOS# (config bandwidth-management) view statistics bwm_class 

Example 

SGOS# (config bandwidth-management) view statistics http 



Class Name: 


http 


Parent : 


<none> 


Minimum Bandwidth : 


unspecified 


Maximum Bandwidth : 


unlimited 


Priority : 


0 


Total Bytes: 


0 bytes 


Total Packets: 


0 pkts 


Dropped Packets: 


0 pkts 


Current Bandwidth: 


0 kbps 


Current Packet Rate : 


0 pps 


Queue Length: 


0 bytes 


Parent 


The class name of the parent of this class. 


Minimum Bandwidth 


The maximum bandwidth setting for this class. 


Maximum Bandwidth 


The minimum bandwidth setting for this class. 


Priority 


The priority level for this class. 
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Total Bytes 


The total number of bytes served. 


Total Packets 


The total number of packets served. 


Dropped Packets 


Total number of packets dropped (packets in the queue that are 
dropped because the queue length is reached). 


Current Bandwidth 


Current bandwidth value (in kilobits per second). 


Current Packet Rate 


Current packets-per-second value. 


Queue Length 


Maximum length allowed for the queue of packets that lack 
available bandwidth but are waiting for bandwidth to become 
available. 



To clear bandwidth management statistics: 

1. To clear bandwidth management statistics for all bandwidth management classes, 
enter the following command at the prompt: 

SGOS# clear- statistics bandwidth-management 

2. To clear bandwidth management statistics for a particular class, enter the following 
command at the prompt: 

SGOS# clear- statistics bandwidth-management class bandwidth_class_name 

Using Policy to Manage Bandwidth 

After creating and configuring bandwidth management classes, create policy rules to 
classify traffic flows using those classes. Each policy rule can only apply to one of four 
traffic flow types: 

□ Client inbound 

□ Client outbound 

□ Server inbound 

□ Server outbound 

You can use the same bandwidth management classes in different policy rules; one class 
can manage bandwidth for several types of flows based on different criteria. However, 
any given flow is always be counted as belonging to a single class. If multiple policy rules 
match a flow and try to classify it into multiple bandwidth classes, the last classification 
done by policy applies. 

To manage the bandwidth classes you have created, you can either compose CPL (see 
"CPL Support for Bandwidth Management" on page 67 below) or you can use VPM (see 
"VPM Support for Bandwidth Management" on page 68). To see examples of policy using 
these methods, see "Bandwidth Allocation and VPM Examples" on page 68 or "Policy 
Examples: CPL" on page 75. 

CPL Support for Bandwidth Management 

You must use policy to classify traffic flows to different bandwidth classes. Refer to 
Volume 11: Content Policy Language Guide for more information about writing and 
managing policy. 
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CPL Triggers 

You can use all of the CPL triggers for BWM classification (refer to Volume 11: Content 
Policy Language Guide for information about using CPL triggers). Basing a bandwidth 
decision on a trigger means that the decision does not take effect until after the 
information needed to make that decision becomes available. For example, if you set the 
CPL to trigger on the MIME type of the HTTP response, then the HTTP headers must be 
retrieved from the OCS before a classification can occur. The decision to retrieve those 
headers occurs too late to count any of the request bytes from the client or the bytes in the 
HTTP response headers. However, the decision affects the bytes in the body of the HTTP 
response and any bytes sent back to the client. 

Supported CPL 

Bandwidth class can be set with policy on each of these four traffic flows: 

□ limitjbandwidth. client. inbound(none | bwm_class) 

□ limit_bandwidth.client.outbound(none | bwmjclass) 

□ limit_bandwidth.server.inbound(none | bwmjclass) 

□ limit_bandwidth.server.outbound(none | bwmjclass) 

If you set policy to none, the traffic is unclassified and is not to be bandwidth-managed. 

VPM Support for Bandwidth Management 

You can manage bandwidth using VPM in the Action column of four policy layers: Web 
Access, DNS Access, Web Content, and Forwarding Layers. For more information about 
using VPM to manage bandwidth, refer to Volume 7: VPM and Advanced Policy. For 
examples of bandwidth management scenarios using VPM, see "Bandwidth Allocation 
and VPM Examples" below. 

Bandwidth Allocation and VPM Examples 

This section illustrates how to use the VPM to allocate bandwidth, arrange hierarchies, 
and create policy. It describes an example deployment scenario and the tasks an 
administrator must accomplish to manage the bandwidth for this deployment. For 
specific instructions about allocating bandwidth, see "Configuring Bandwidth 
Allocation" on page 61. For examples of CPL bandwidth management tasks, see "Policy 
Examples: CPL" on page 75. 

Task One: Bandwidth Allocation 

The administrator is responsible for managing the bandwidth of three branch offices. He 
was told to ensure that each office uses no more than half of its total link bandwidth for 
Web and FTP traffic. The total link bandwidth of each office is as follows: 

□ Office A: 1.5 Mb 

□ Office B: 1 Mb 

□ Office C: 2 Mb 

He creates one bandwidth class for each of the three offices and configures the maximum 
bandwidth to an amount equal to half of the total link bandwidth of each, as shown 
below. He also creates policy rules for each class, as described below in "Task One: VPM". 
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Each of the classes above has a maximum set at an amount equal to half of the total link 
bandwidth for each office. A hierarchy does not exist in this scenario. 



Task One: VPM 

The administrator has created one bandwidth class for each office, setting a maximum 
bandwidth on each one equal to the half of the total link bandwidth of each. Now he must 
create policy rules to classify the traffic flows. 



FTP/HTTP Limitations 
No. Source 

l[ 



Service 
lAnv 



rExisting Source Objects 



Time 

lAnv 



Action Track 

IQ Deny Ihlorte 



t Source Object 



Show: All (sort by object-name) 



Authenticated User 
Streaming Clignt 



Client Hostname Unavailable 



Add Client IP/Subnet Object 



IP Address: 10.1.1.1 



Subnet Mask: 255 .255 .255 255| 



J1 



Add 




Close 




Help 



The administrator launches the VPM and creates a new Web Access Layer, naming it FTP/ 
HTTP Limitations. He selects the Client IP Address/Subnet object in the Source column, 
filling in the IP address and mask of the subnet used by Office_A. 
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He selects a Combined Service Object in the Service column, naming it FTP/HTTP and 

adding a Client Protocol for FTP and for HTTP. 




He adds both protocols to the At least one of these objects field. 



C Add Bandwidth Management Object 



Name: Office_A 



Limit bandwidth on: 



® Client side 




O Inbound 


O Server side 




® Outbound 



Bandwidth class: none v 







none 




OK 




Cai 


ChildA 


Help 









In the Action column, he selects Manage Bandwidth, naming it Office_A and setting it to 
manage the bandwidth of Office_A on the Client side in the Outbound direction. 
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He adds two more similar rules for the other two offices. He is able to reuse the same 
Combined Service Object in the Service column, but must add new objects specific to each 
office in the Source and Action columns. The order of the rules does not matter here, 
because each office, and thus each rule, is distinct because of its IP address/ subnet mask 
configuration. 

Task Two: Bandwidth Allocation 

A few days later, the administrator gets a visit from the CEO of his company. She wants 
him to fix it so that she can visit any of the branch offices without having her own Web 
and FTP access slowed down unnecessarily. 

The administrator creates two more classes for each office: one for the CEO and another 
for everyone else (employees). He sets the parent class of each new class to the 
appropriate class that he created in Task One. For example, he creates Emp_A and CEO_A 
and sets their parent class to Office_A. He also sets a priority level for each class: 0 (the 
lowest) for employees and 1 for the CEO. He then uses VPM to create additional policy 
rules for the new classes (see "Task Two: VPM” below). This figure shows the hierarchical 
relationship among all of the classes. 




The administrator now has three separate hierarchies. In each one, bandwidth is limited 
by the configuration of the parent class, and the two child classes are prioritized to 
determine how they share any unused bandwidth. Because no minimums have been set, 
the highest priority class has the first opportunity to use all of the available bandwidth; 
whatever is left then goes to the next priority class. 

Priority levels are only effective among the classes in the same hierarchy. This means that 
the priority levels for the Office_A hierarchy do not affect the classes in the Office_B or 
Office_C hierarchies. 

Task Two: VPM 

Because the CEO wants to prioritize FTP and HTTP access among employees and herself, 
the administrator must create additional bandwidth classes (as described above in "Task 
Two: Bandwidth Allocation") and write policy rules to classify the traffic for the new 
classes. 
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Service Time Action Track Comment 




He first edits each of the three VPM rules for the three offices. He edits each the Manage 
Bandwidth objects, changing the name of the objects to Emp_A, Emp_B, and Emp_C and 
changes the bandwidth class to the corresponding employee class. 




Next, he creates three more rules for the CEO, moving them above the first three rules. For 
the CEO rules, he selects the same combined FTP/HTTP object in the Service column; in the 
Action column, he selects a Manage Bandwidth object configured for client side /outbound, 
as before, but this time, he names the objects CEO_A, CEO_B, and CEO_C and selects the 
corresponding CEO bandwidth class. In the Source column, he creates a Combined Source 
Object, naming it for the CEO. He combines the Client IP/subnet object already created for 
each office with a User object that he creates for the CEO. 
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The administrator places all three CEO rules above the employee rules, because the SG 
appliance looks for the first rule that matches a given situation and ignores the remaining 
rules. If he had placed the CEO rules below the employee rules, the SG appliance would 
never get to the CEO rules because the CEO's Web surfing client IP address matches both 
the CEO rules and the employee rules, and the SG appliance would stop looking after the 
first match. With the CEO rules placed first, the SG appliance applies the CEO rules to the 
CEO's Web surfing, and an employee's Web surfing does not trigger the CEO rules and 
instead skips ahead to the appropriate employee rule. 

Task Three: Bandwidth Allocation 

It soon becomes apparent that CEO visits are causing problems for the branch offices. At 
times, she uses all of the available bandwidth, resulting in decreased productivity 
throughout the office she visits. Also, management has complained that they have been 
given the same priority for FTP and HTTP traffic as regular employees, and they are 
requesting that they be given priority over employees for this type of traffic. 

First, the administrator creates two new classes for each office. In this example, we look at 
the classes and configurations for the first office only. He creates a class called Staff_A and 
sets a minimum bandwidth of 500 kbps on it. He also creates a class called Mgmt A, 
setting the priority to 1 and the parent to Staff_A. He edits the class Emp_A, setting the 
parent to Staff_A. Finally, he edits the class CEO_A, changing the priority to 2. The 
resulting hierarchy is illustrated below. To see what the administrator did to the policy 
rules, see "Task Three: VPM" on page 74. 




total of 500 kbps. The CEO's priority level has no effect until that minimum is satisfied. 
This means that the CEO can only use 250 kbps of bandwidth if the rest of the staff are 
using a total of 500 kbps. It also means that the CEO can use 750 kbps if no one else is 
using bandwidth at the time. In fact, any of the classes can use 750 kbps if the other classes 
use none. 



Priority levels kick in after all of the minimums are satisfied. In this example, if the staff 
requests more than 500 kbps, they can only receive it if the CEO is using less than 250 
kbps. Now notice that the minimum setting for the staff is set on the parent class, Staff_A, 
and not on the child classes, Emp_A or Mgmt_A. This means that the two child classes, 
representing employees and management, share a minimum of 500 kbps. But they share it 
based on their priority levels. This means that management has priority over employees. 
The employees are only guaranteed a minimum if management is using less than 500 
kbps. 
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Task Three: VPM 

The administrator has added additional classes for each office and edited the existing 
employee classes, as described above in "Task Three: Bandwidth Allocation”. One of the 
new classes he added for each office is a parent class that does not have traffic classified to 
it; it was created to provide a minimum amount of bandwidth to its child classes. Not 
every class in the hierarchy has to have a traffic flow. This means that he needs to add just 
three more rules for the three new management classes. For the management rules, he 
selects the same combined FTP/HTTP object in the Service column; in the Action column, 
he selects a Manage Bandwidth object configured for client side / outbound with the 
bandwidth class one of the management classes (Mgmt_A, Mgmt B, or Mgmt_C). In the 
Source column, he creates a Combined Source Object containing the subnet object for the 
office and the Group object for management. 

The management rules must go above the employee rules, although it does not matter 
where they are placed in relation to the CEO rules. This would not be true if the CEO was 
part of the same group as management, however. If that were true, the CEO rules would 
still need to go on top. 

Task Four: Bandwidth Allocation 

The administrator decided later that he needed to guarantee employees some bandwidth. 
He configures a minimum for the class Emp_A, as illustrated below. 




He decides to leave the minimum on the parent class Staff_A and not to set a minimum for 
the class Mgmt_A. This is okay, because the minimum of the parent class is available to its 
children if the parent class does not use all of it, and the only way that the CEO can get 
more than 250 kbps is if the employees and management combined use less than 500. 

This last change does not require additional changes to policy; the administrator has 
added a minimum to a class that he has already classified for traffic using policy. 

In the above scenario, the class called Staff_A does not have traffic configured for it — it 
was created to guarantee bandwidth minimums for its child classes. However, if it were 
configured for traffic, it would have a practical minimum of 300 kbps. The practical 
minimum of a parent class is equal to its assigned minimum bandwidth minus the 
minimums of its children. In that case, if the parent class Staff_A used 300 kbps and the 
child class Emp_A used 200 kbps, the child class Mgmt_A would not receive any 
bandwidth unless the class CEO_A was using less than 250 kbps. Under those 
circumstances, the administrator probably also needs to create a minimum for 
management. 
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Task Five: Bandwidth Allocation 

The CEO makes another request, this time for the main office, the one the administrator 
himself works from. This office uses the content filtering feature of the SG appliance to 
control the types of Web sites that employees are allowed to view. Although the office uses 
content filtering, access to sports sites is not restricted because the CEO is a big fan. 

The administrator creates a bandwidth management class called Sports with a maximum 
bandwidth of 500 kbps and launches VPM to create policy for this class as described 
below. 

Task Five: VPM 

To classify traffic for the Sports class, the administrator opens VPM, creates a Web Access 
Layer, and sets the Destination column to the Category object that includes sports viewing 
(content filtering is already set up in VPM). He sets the Action column to the Manage 
Bandwidth object, selecting Server side/inbound and the Sports bandwidth class he created. 
After installing the policy and verifying that bandwidth management is enabled, he is 
finished. 

Policy Examples: CPL 

The examples below are complete in themselves. The administrator uses CLI to create and 
configure bandwidth management classes and writes CPL to classify traffic flow for these 
classes. These examples do not make use of a bandwidth class hierarchy. For examples of 
hierarchies, see "Bandwidth Allocation and VPM Examples" on page 68. 

Example One: CPL 

In this example, the administrator of a college is asked to prevent college students from 
downloading MP3 files during peak hours, while still allowing the music department to 
download MP3 files at any time. The CPL triggers used are authentication and/ or source 
subnet and MIME type. The action taken is to limit the total amount of bandwidth 
consumed by students to 40 kbps. 

CLI commands: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) create mp3 
SGOS# (config bandwidth-management) edit mp3 
SGOS# (config bw-class mp3) max-bandwidth 40 

CPL: 

define condition student_mp3_weekday 

client_address=student_subnet response_header . Content-Type= "audio/ 
mpeg" \ 

weekday=1..5 hour=9..16 
end condition 

<proxy> 

condition=student_mp3_weekday limit_bandwidth . server . inbound (mp3 ) 

Example Two: CPL 

In this example, an administrator must restrict the amount of bandwidth used by HTTP 
POST requests for file uploads from clients to 2 Mbps. The CPL trigger used is request 
method, and the action taken is to throttle (limit) the amount of bandwidth used by client 
side posts by limiting inbound client side flows. 

CLI: 
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SGOS# (config) bandwidth-management 

bandwidth-management) create http post 

SGOS# (config bandwidth-management) edit http post 

SGOS# (config bw-class http_post) max-bandwidth 2000 

CPL: 

define condition http_posts 
http . method=POST 
end condition 

<proxy> 

condition=http_posts limit_bandwidth . client . inbound (http_post) 

Example Three: CPL 

In this example, the administrator of a remote site wants to limit the amount of bandwidth 
used to pre-populate the content from headquarters to 50 kbps during work hours. The 
CPL triggers used are current-time and pre-population transactions. The action taken is to 
limit the total amount of bandwidth consumed by pre-pop flows. 

CLI: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) create pre-pop 
SGOS# (config bandwidth-management) edit pre-pop 
SGOS# (config bw-class pre-pop) max-bandwidth 50 

CPL: 

define condition prepop_weekday 

content_management=yes weekday=l . . 5 hour=9..16 
end condition 

<proxy> 

condition=prepop_weekday limit_bandwidth . server . inbound (pre-pop) 
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This chapter discusses device authentication, which is a mechanism that allows devices 
to verify each others' identity; devices that are authenticated can be configured to trust 
only other authenticated devices. 



Note: SG appliance authentication is always used in association with other SGOS 

features. For example, you can use appliance authentication with the ADN 
implementation of secure tunnels. The secure tunnels feature uses authentication, 
the process of verifying a device's identity, with authorization, the process of 
verifying the permissions that a device has. For information on secure tunnels and 
appliance authentication, see Section D: "Securing the ADN Network" on page 31. 



Introduction 

Device authentication is important in several situations: 

□ Securing the network. Devices that are authenticated have exchanged certification 
information, verified each others' identity and know which devices are trusted. 

□ Securing protocols. Many protocols require authentication at each end of the 
connection before they are considered secure. 

This chapter discusses the following topics: 

□ "SG Appliance Overview". 

□ "Appliance Certificates and Device Authentication Profiles" on page 78. 

□ "Creating an Authentication Profile" on page 83. 

□ "Related CLI Syntax to Manage Device Authentication" on page 85. 

□ "Obtaining a Non Blue Coat Appliance Certificate" on page 83. 

□ "Related CLI Syntax to Manage Device Authentication" on page 85. 

SG Appliance Overview 

The Blue Coat implementation allows devices to be authenticated without sending 

passwords over the network. Instead, a device is authenticated through certificates and 

profiles that reference the certificates. Both the profile and the referenced certificate are 

required for device authentication. 

□ Certificates: Certificates contain information about a specific device. Blue Coat runs 
an Internet-accessible Certificate Authority (CA) for the purpose of issuing 
appliance certificates to SGOS devices. You can also create your own appliance 
certificates. 

□ Profiles: A profile is a collection of information used for device-to-device 
authentication, including if the device has a certificate and if the certificates of other 
devices should be verified. The built-in profile is called bluecocit-appliance-certificcite 
and references the appliance certificate on your SG appliance; you can create 
additional profiles. 
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Note: Authenticating the SG appliance and authenticating the SG appliance server 

name are two different procedures that require two different certificates. For 
information on authenticating server names, refer to Volume 5: Securing the Blue Coat 
SG Appliance. 



Appliance Certificates and Device Authentication Profiles 

In the Blue Coat implementation of device authentication, both an appliance certificate 
and a device authentication profile that references the appliance certificate keyring are 
required for device authentication to be successful. Each device to be authenticated must 
have an appliance certificate and a profile that references that certificate. 

Note that device authentication does not take effect unless the profile is enabled; for 
example, if you use WAN optimization, you enable the profile on the Configuration > App. 
Delivery Network > General > Device Security tab. 

About SG Appliance Certificates 

SG appliances come with a cryptographic key that allows the system to be authenticated 
as an SG appliance when an appliance certificate is obtained. 

An appliance certificate is an X.509 certificate that contains the hardware serial number of 
a specific SG device as the CommonName (CN) in the subject field. This certificate then 
can be used to authenticate the SG appliance whose hardware serial number is listed in 
the certificate. Information from the presented certificate is extracted and used as the 
device ID. 

Blue Coat runs an Internet-accessible CA for the purpose of issuing appliance certificates. 
The root certificate for the Blue Coat CA is automatically trusted by SGOS for device 
authentication. These Blue Coat-signed certificates contain no authorization information 
and are valid for five years. 

You can provide your own device authentication certificates for the SG appliances on your 
network if you prefer not to use the Blue Coat CA. 

About Device Authentication Profiles 

A device authentication profile contains the information related to device authentication: 

□ The name of the keyring that contains the private key and certificate this device uses to 
authenticate itself. The default is appliance-key. (For information on private and 
public keys, refer to Volume 5: Securing the Blue Coat SG Appliance.) 

□ The name of the CA Certificate List (CCL) that contains the names of certificates of 
CAs trusted by this profile. If another device offers a valid certificate signed by an 
authority in this list, the certificate is accepted. The default is appliance-ccl. 

□ Verification of the peer certificate. 

When the SG appliance is participating in device authentication as an SSL client, the 
peer certificate verification option controls whether the server certificate is validated 
against the CCL. If verification is disabled, the CCL is ignored. 

When the SG appliance is participating in device authentication as an SSL server, the 
peer certificate verification option controls whether to require a client certificate. If 
verification is disabled, no client certificate is obtained during the SSL handshake. The 
default is verify-peer-certif icate enabled. 
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□ Specification of how the device ID authorization data is extracted from the certificate. 
The default is $( subject. CN) . 

□ SSL cipher settings. The default is AES256-SHA. 

Each Blue Coat appliance has an automatically-constructed profile called bluecoat- 
appliance-certificate that can be used for device-to-device authentication. This profile 
cannot be deleted or edited. 

If you cannot use the built-in profile because, for example, you require a different cipher 
suite or you are using your own appliance certificates, you must create a different profile, 
and have that profile reference the keyring that contains your certificate. 



Note: If you do not want to use peer verification, you can use the built-in passive- 

attack-detection-only profile in place of the bluecoat-appliance-certificate profile. 

This profile uses a self-signed certificate and disables the verify-peer option, so that 
no authentication is done on the endpoints of the connection. The traffic is encrypted, 
but is vulnerable to active attacks. 

This profile can be used only when there is no threat of an active man-in-the-middle 
attack. Like the bluecoat-appliance certificate profile, the passive-attack-detection-only 

profile cannot be edited or deleted. 



If you create your own profile, it must contain the same kind of information that is 
contained in the Blue Coat profile. To create your own profile, skip to "Creating an 
Authentication Profile" on page 83. 

Obtaining an SG Appliance Certificate 

In many cases, if you have Internet connectivity, an appliance certificate is automatically 
fetched by the SG appliance, and no human intervention is required. In other cases, if the 
Internet connection is delayed or if you do not have Internet access, you might have to 
manually initiate the process of obtaining an appliance certificate. 

How you obtain an appliance certificate depends upon your environment: 

□ If the device to be authenticated has Internet connectivity and can reach the Blue Coat 
CA server, continue with "Automatically Obtaining an Appliance Certificate" on page 
80. 

□ If the device to be authenticated cannot reach the Blue Coat CA server, you must 
acquire the certificate manually; continue with "Manually Obtaining an Appliance 
Certificate" on page 80. 

After the certificate is obtained, you must configure the device to use the profile you 
choose to use. For information on configuring the device to use the profile, see Chapter 2: 
"Configuring an Application Delivery Network". 

If you are configuring device authorization as well as authentication, configure device 
authentication before authorization. For more information on device authorization, see 
Chapter 2: "Configuring an Application Delivery Network". 
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Important: Only the following SG platforms support appliance certificates: 

□ SG200 (manufactured after August 1, 2006) 

□ SG510 

□ SG810 

□ SG8100 

If you attempt to obtain an appliance certificate for other platforms (through 

Configuration > SSL > Appliance Certificates > Request appliance certificate), the request 
fails with the following error message: 

□ Request failed: Signing server reported error: No such serial number serial number. 

If you receive this message, you cannot use Blue Coat appliance certificates, but you can 
create your own appliance certificates for use in a secure network. For more 
information, see "Obtaining a Non Blue Coat Appliance Certificate" on page 83. 



Automatically Obtaining an Appliance Certificate 

The appliance attempts to get the certificate completely automatically (with no user 
intervention) if it can connect to the Blue Coat CA server at boot time or within about five 
minutes of being booted. If the appliance does not have a certificate (for example, it had 
one until you did a restore-defaults factory-defaults command) it attempts to get 
one on every boot. Once the appliance gets a certificate, that certificate is used until 
another restore-defaults factory-defaults command is issued. 

If Internet connectivity is established more than five minutes after the system is booted, 
you might need to complete the following steps. 

To automatically obtain an appliance certificate: 

1. Select Configuration > SSL > Appliance Certificates > Request Certificate. 

2. Click Request appliance certificate. 

The Blue Coat CA server does validation checks and signs the certificate. The 
certificate is automatically placed in the appliance -key keyring. Note that the 
appliance -key keyring cannot be backed up. The keyring is re-created if it is missing 
at boot time. 

Manually Obtaining an Appliance Certificate 

Complete the following steps to obtain an appliance certificate manually. The overview of 
the procedure is to: 

□ Generate a appliance certificate signing request and send it to the Blue Coat CA server 
for verification and signature. 

□ Import the signed certificate into the SG appliance. 

To generate a CSR: 

1. Select Configuration > SSL > Appliance Certificates > Request Certificate. 

2. Select Create CSR. 
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3. Copy the certificate request, including the certificate request signature. Be sure to 
include the "Begin Certificate" and "End Certificate" statements, as well as the "Begin 
CSR Signature" and "End CSR Signature" statements. 

4. Click OK. 

5. Go to the Blue Coat CA Server Website at https:/ / abrca.bluecoat.com/ sign-manual/ 
index.html. 





Blue Coat - 


ABRCA Manual Form 




CSR+Signature 


| BEGIN CERTIFICATE REQUEST 

M I IB x z CC AT AC AQAwgYYx C z A J B gNVB A YT A lVTMQs wC Q YD VQQ I E ¥ J D QTE S MB AG A 1 UE 
B x M J U3 Vub n 1 2 YUx 1 HS AwHgYDVQQKE x dCb HV 1 1 ENv YXQgU3 1 z dGVt c y wgS U5 j L j E f 
MB0GAlUECxMWQmxlZSBDb2F0IFNHMj AwIFNlcml 1 czETHBEGA1UEAxHKNDUwNTA 2 
HD Ay HD C B n z AWB gkqhk i G9 wO B AQE F A AOB 3 QAwg YkC g YE At 1 Y3 S a I t s 6 AD Y8 B P YhVb 
Hr v A/ aRs OE d 6 OC wws ux i F S THn3 i j D ug5 1 1 T5 D D vf mx y 4 Yc gP 7 vdTae Vdqe QD B wkH 
F p j x x Uf j THX INge B TJKhTH8 UL c 0/ gB a8 z 7 c UUr y x y GS 9FS3H2ZBZXSx SvQT 1 9 z Uu3 
2 X A3 Qt 1 1 r 8 RH7 HH 1 db P oxnr 0 C A wE A Aa A AH AO GC S qGS lb 3 D QE B B AU A A4 GB AHB i kVOc 
Tj H8 zDmPtt I I7dHNCwinf P Iy3 zeyppdr HFL 1 JcnJ j wqhlXr ndN7WHYUXEwhYJtU9p 
70kyFs+giBt I zdd8f nZaeF4 JXNC zSf LqWnpKOj TBA9¥LTHc IThIHp 1UZE/ T1 1DRS 
kZ6AfyhJQGhxmKuAi8LLR3PHO5Y0owxo8A17 

END CERTIFICATE REQUEST 

BEGIN CSR SIGNATURE 

KsrqFGa5jb2Az+GL/Hm90FmnBzLg0svAwBbaYD64qNm3VH17ADaMw2LfrZlD13ez 






B0gxKJEBU5w7TULG23 QJV3 Xp wP 7 XOb 6ms 1 e kg/ XPN Z 2 OmoN j 1 3 Vr e J +A9 us Yp Uhh 
56qFKf IcivnDchukrhI= 

END CSR SIGNATURE 






[ Generate Cert ] 



6. Paste the CSR and signature into the CSR panel. 
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7. Click Generate Cert. 

The signed certificate displays, and can be pasted into the appliance-key keyring. 

BEGIN CERTIFICATE 

MIIF/jCCBOagAwIBAgICAMowDQYJKoZIhvcNAQEFBQAwgbYxCzAJBgNVBAYTAlVT 
MRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTdW5ueXZhbGUxIDAeBgNV 
BAoTFO JsdWUgQ29hdCBTeXN0ZWlzLCBJbmMuMRkwFwYDVQQLExBCbHVlIENvYXQs 
IEFCUkNBMRswGQYDVQQDExJhYnJj YS5ibHVlY2 9hdC5 jb2 0xJDAiBgkqhkiG9w0B 
CQEWFXN5c2FkbWluQGJsdWVjb2F0LmNvbTAeFw0wNzAxMjkyMDM5NDdaFw0xMjAx 
MjkyMDM5NDdaMIGGMQswCQYDVQQGEwJVUzELMAkGAlUECBMCQ0ExE j AQBgNVBAcT 
CVNlbm55dmFsZTEgMB4GAlUEChMXQmxlZSBDb2F0IFN5c3RlbXMsIEluYy4xHzAd 
BgNVBAsTFkJsdWUgQ29hdCBTRzIwMCBTZXJpZXMxEzARBgNVBAMTC j AlMDUwNj Aw 
OTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMBUmCuKSsSd+D5kJQiWu3OG 
DNLCvf 7SyKK5+SBCJU2iKwP5+Ef iQ5 JsScWJghtIo94EhdSC2zvBPQqWbZAJXN74 
k/yM4w9uf j f o+G7xPYcMrGmwVBGnXbEhQkagclFH2orINNY8SVDYVLlV4dRM+0at 
YpEiBmSxipmRSMZL4kqtAgMBAAG j ggLGMI ICwj AJBgNVHRMEAj AAMAsGAlUdDwQE 
AwIE8DBOBgNVHSUERzBFBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMEBgsr 
BgEEAf E lAQECAQYLKwYBBAHx JQEBAg IGCysGAQQB 8 SUBAQIDMB OGAlUdDgQWBBS F 
NqC2ubTI70T5 j +KqCPGlSDO7DzCB6wYDVR0 j BIHjMIHggBSwEYwcqlN6GlZhpcXn 
OTIu8fNelaGBvKSBuTCBtjELMAkGAlUEBhMCWMxEzARBgNVBAgTCkNhbGlmb3Ju 
aWExE j AQBgNVBAcTCVNlbm55dmFsZTEgMB4GAlUEChMXQmxlZSBDb2F0IFN5c3Rl 
bXMsIEluYy4xGTAXBgNVBAsTEEJsdWUgQ2 9hdCwgQUJSQ0ExGzAZBgNVBAMTEmFi 
cmNhLmJsdWVjb2F0LmNvbTEkMCIGCSqGSIb3DQEJARYVc31zYWRtaW5AYmxlZWNv 
YXQuY29tggkAhmhbUPEEb60wgZ8GCCsGAQUFBwEBBIGSMIGPMEkGCCsGAQUFBzAB 
hj lodHRwczovL2FicmNhLmJsdWVjb2F0LmNvbS9 j Z2ktYmluL2Rldml j ZSlhdXRo 
ZW50aWNhdGlvbi9vY3NwMEIGCCsGAQUFBzAChjZodHRw0i8vYWJyY2EuYmxlZWNv 
YXQuY2 9tL2Rldml j ZSlhdXRoZW5 0aWNhdGlvbi9 j YS5 j Z2kwSAYDVR0fBEEwPzA9 
oDugOYY3aHROcDovL2FicmNhLmJsdWVjb2FOLmNvbS9kZXZpY2UtYXVOaGVudGlj 
YXRpb24vQl JMLmNybDBf BgNVHSAEWDBWMFQGCisGAQQB8SUBAQEwRj BEBggrBgEF 
BQcCARY4aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj 
YXRpb24vcnBhLmh0bWwwDQYJKoZIhvcNAQEFBQADggEBACIhQ7Vu6aGJBpxP255X 
d2/Qw7NiVsnq01Ay913QZlieFfVATJnCeSrH+M9B/2XtnRxVTO/ZWrf 4GbsdYqTF 
hc9 j R/ IwKu6kZq3 2Dqo8qFU50zbAEzT2oebB5QgwuJtHcJHggp9PS9uS2 7qAnGQK 
OeB2bYc j WtMvTvr50iDOV69BEQz+VXos8QiZmRHLVnebQS j 13bilw3Vj Bw31tCmc 
clgz0SlN9ZmJdRU/PlWdNVqD4OLqcMZQ53HqcdWNEzN2uvigIb//rM7XazK7xIaq 
r23/ +BsZlYKAeVMq3PEmxaA2zLzO+ j f 7 9a8ZvIKrF2 7nNuTN7NhFL/V6pWNElo9A 
rbs = 

END CERTIFICATE 

To import a certificate onto the SG appliance: 

1. Copy the certificate to your clipboard. Be sure to include the "Begin Certificate" and 
"End Certificate" statements. 

2. Select Configuration > SSL > Keyrings. 

3. Select the keyring that is used for device authentication. The keyring used by the 
bluecoat-appliance-certificate profile is the appliance-key keyring. 

4. Click Edit/View in the Keyrings tab. 
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5. In the Certificate panel, click Import. 

6. Paste the certificate you copied into the dialog box. Click OK. 

The certificate should display in the SSL Certificates Pane, associated with the keyring 
you selected earlier. 

Obtaining a Non Blue Coat Appliance Certificate 

If you run your own certificate signing authority for device authentication, complete the 
following steps: 

1. Create a keyring for the appliance's certificate. For information on creating a keyring, 
refer to Volume 5: Securing the Blue Coat SG Appliance. 

2. Generate the certificate signing request and get it signed. For information on creating 
a CSR, refer to Volume 5: Securing the Blue Coat SG Appliance. 



Note: You cannot put a Blue Coat appliance certificate into a keyring you create 

yourself. 



3. Create a CA certificate list. For information on creating a CCL, refer to Volume 5: 
Securing the Blue Coat SG Appliance 

a. Import the CA's root certificate. 

b. Add the certificate to the CCL. 

4. Create a device authentication profile. (To create a profile, see "Appliance Certificates 
and Device Authentication Profiles" on page 78.) 

5. Associate the profile with the keyring and CCL. The keyring and CCL must already 
exist. 

Adjust other parameters, including authorization data extractor (if the certificate is to 
be used for authorization), as needed. 

Configure each application that uses device authentication to reference the newly created 
profile, and set up its whitelist. To associate the device with the profile, see Chapter 2: 
"Configuring an Application Delivery Network". 

Creating an Authentication Profile 

Am authentication profile only needs to be created if you cannot use the built-in bluecoat- 

appliance-certificate profile without modification; note that the bluecoat-appliance- 
certificate profile cannot be deleted or edited. 

Additional profiles with different settings can be created; for example, if you require a 
different cipher setting than what the bluecoat-appliance-certificate profile uses, you can 
create a profile with the different cipher suite. 

To create a new authentication profile: 

1. Select Configuration > SSL > Device Authentication > Profiles. 

2. Click New. 
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3. Name: Give the profile a meaningful name. The only valid characters are 
alphanumeric, the underscore, and hyphen, and the first character must be a letter. 

4. Keyring: From the drop-down list, select the keyring you want to use for device 
authentication. 



Note: You must create a new keyring for device authentication if you do not use the 
appliance -key keyring. The keyrings shipped with the Blue Coat SG are dedicated to 
other purposes. For information on creating a new keyring, refer to Volume 5: Securing 
the Blue Coat SG Appliance. 



5. CCL: From the drop-down list, select the CA Certificate List you want to use. 

6. Device ID extractor: The field describes how device ID information is extracted from a 
presented certificate. The string contains references to the attributes of the subject or 
issuer in the form $ (subject . attr [ . n] ) or $ (issuer.attr [ . n] ) , where attr is the 
short-form name of the attribute and n is the ordinal instance of that attribute, 
counting from 1 when the subject is in LDAP (RFC 2253) order. If n is omitted, it is 
assumed to be 1. 

The default is $ ( sub j ect . CN) ; many other subject attributes are recognized, among 
them OU, O, L, ST, C, and DC. 

7. Verify peer: This setting determines whether peer certificates are verified against the 
CCL or whether client certificates are required. 

8. Selected cipher suites: If you want to use a different cipher suite, click Edit cipher 
suites. 
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9. Select the cipher suite or suites you want to use. Click Add to add the cipher suite to 
the list of selected cipher suites. Cipher suites that you do not want to use should be 
removed from the selected list. 

10. Click OK when done. 

11. Select Apply to commit the changes to the SG appliance. 



Related CLI Syntax to Manage Device Authentication 

□ To enter configuration mode: 

SGOS# (conf ig) ssl 

□ The following device-authentication commands are available: 

SGOS# (conf ig ssl) create device-authentication-profile profile_name 
keyring_ID 

SGOS#(config ssl) edit device-authentication-profile test 
SGOS#(config device-auth test) cipher-suite cipher-suite 
SGOS# (config device-auth test) ccl ccl_name 
SGOS# (conf ig device-auth test) device-id device_ID 
SGOS# (config device-auth test) exit 

SGOS# (config device-auth test) keyring-id keyring_ID 
SGOS# (config device-auth test) verify-peer [enable | disable] 
SGOS# (config device-auth test) view 
SGOS# (config ssl) request-appliance-certificate 
SGOS# (config ssl) view appliance-certificate-request 
SGOS# (config ssl) view device-authentication-profile 
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Using IP address failover, you can create a redundant network for any explicit proxy 
configuration. If you require transparent proxy configuration, you can create software 
bridges to use failover. For information on creating software bridges, refer to Volume 2: 
Getting Started. 



Note: If you use the Pass-Through adapter for transparent proxy, you must create a 
software bridge rather than configuring failover. For information on using the Pass- 
Through adapter, refer to Volume 2: Getting Started. 



Using a pool of IP addresses to provide redundancy and load balancing. Blue Coat 
migrates these IP addresses among a group of machines. 

This section discusses: 

□ "About Failover" . 

□ "Configuring Failover" on page 88. 

About Failover 

Failover allows a second machine to take over if a first machine fails, providing 
redundancy to the network through a master /slave relationship. In normal operations, 
the master (the machine whose IP address matches the group name) owns the address. 
The master sends keepalive messages ( advertisements ) to the slaves. If the slaves do not 
receive advertisements at the specified interval, the slave with the highest configured 
priority takes over for the master. When the master comes back online, the master takes 
over from the slave again. 

The Blue Coat failover implementation resembles the Virtual Router Redundancy 
Protocol (VRRP) with the following exceptions: 

□ A configurable IP multicast address is the destination of the advertisements. 

□ The advertisement interval is included in protocol messages and is learned by the 
slaves. 

□ A virtual router identifier (VRID) is not used. 

□ Virtual MAC addresses are not used. 

□ MD5 is used for authentication at the application level. 

Masters are elected, based on the following factors: 

□ If the failover mechanism is configured for a physical IP address, the machine 
owning the physical address have the highest priority. This is not configurable. 

□ If a machine is configured as a master using a virtual IP address, the master has a 
priority that is higher than the slaves. 

When a slave takes over because the master fails, an event is logged in the event log. 
No e-mail notification is sent. 



87 



Volume 6: Advanced Networking 



Configuring Failover 

Before you begin, ensure that software bridges already exist. For information on 
configuring bridges, refer to Volume 2: Getting Started. 

You also must decide which machine is the master and which machines are the slaves, and 
whether you want to configure explicit proxy or transparent proxy network. 

When configuring the group, the master and all the systems in the group must have 
exactly the same failover configuration except for priority, which is used to determine the 
rank of the slave machines. If no priority is set, a default priority of 100 is used. If two 
appliances have equal priority, the one with the highest physical address ranks higher. 



Note: Configuring failover on an Application Data Network (ADN) is similar to 

configuring failover on other appliances, with the exception that you add a server 
subnet on multiple boxes instead of just one. 



To configure failover: 

1. Select Configuration > Network > Advanced > Failover. 

2. Click New. 




in the fields as appropriate: 

Create a group using either a new IP address or an existing IP address. If the 
group has already been created, you cannot change the new IP address 
without deleting the group and starting over. 

Multicast address refers to a Class D IP address that is used for multicast. It is 
not a virtual IP address. 



3. Fill 

a. 

b. 
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Note: Class D IP addresses (224 to 239) are reserved for multicast. A Class D IP 
address has a first bit value of 1, second bit value of 1, third bit value of 1, and 
fourth bit value of 0. The other 28 bits identify the group of computers that 
receive the multicast message. 



c. Relative Priority refers to a range from 1-255 that is assigned to systems in the 
group. 255 is reserved for the system whose failover group ID equals the real 
IP address. (Optional) Master identifies the system with the highest priority 
(the priority value is greyed out). 

d. (Optional) Advertisement Interval refers to the length of time between 
advertisements sent by the group master. The default is 40 seconds. If the 
group master fails, the slave with the highest priority takes over (after 
approximately three times the interval value). The failover time of the group 
is controlled by setting this value. 

e. (Optional, but recommended) Group Secret refers to a password shared only 
with the group. 

f. Select enabled. 

g. Click OK. 

4. Select Apply to commit the changes to the SG appliance. 



Related CLI Syntax to Configure Failover 

□ To enter configuration mode: 

SGOS# (conf ig) failover 



□ The following subcommands are available: 



SGOS# (config failover) 
SGOS# (config failover) 
SGOS# (config failover 
multicast address 



SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
-or- 

SGOS# (config 
SGOS# (config 



create group_address 
edit group_address 
group_address) multicast-address 



failover 

failover 

failover 

failover 

failover 

failover 



group_address) 

group_address) 

group_address) 

group_address) 



group 

group 



address ) 
address ) 



master 

priority number 
interval seconds 
secret secret 

encrypted- secret encrypted_secret 
enable 



Viewing Failover Statistics 

At any time, you can view statistics for any failover group you have configured on your 
system. 

To view failover status: 

1. Select Statistics > System > Failover. 



89 



Volume 6: Advanced Networking 



Status 



Failover Group: 10.9.16.150 



V 



Failover status: 



Multicast address: 
Local address: 
State: 

Flags: 



224.1.2.3 
10.9.16.150 
MASTER 
R (Real IP) 



2. From the drop-down list, select the group to view. 

The information displayed includes the multicast address, the local address, the state, and 
any flags, where V indicates the group name is a virtual IP address, R indicates the group 
name is a physical IP address, and M indicates this machine can be configured to be the 
master if it is available. 
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To fill requests, the SG appliance must interact not only with the local network, but 

with the upstream network environment. To control upstream interaction, various 

options are supported, such as forwarding, SOCKS gateways, ICP (Internet Caching 

Protocol), and WCCP (Web Cache Control Protocol). 

□ The SG appliance forwarding system — Allows you to define the hosts and groups 
of hosts to which client requests can be redirected. Those hosts can be servers or 
proxies, including additional appliances. Rules to redirect requests are set up in 
policy. 

□ SOCKS gateways — SOCKS servers provide application level firewall protection for 
an enterprise. The SOCKS protocol provides a generic way to proxy HTTP and 
other protocols. For information on configuring SOCKS gateways, see Chapter 13: 
"SOCKS Gateway Configuration" on page 183. 

□ ICP — Internet Caching Protocol (ICP) is a service to handle ICP queries from other 
caching devices looking for cached data. The devices that can access this service can 
be controlled. ICP can also be used by the SG appliance to locate cached data in 
other systems. For information on configuring ICP, see Chapter 9: "Internet 
Caching Protocol (ICP) Configuration" on page 127. 

□ WCCP — WCCP is a Cisco®-developed protocol that allows you to establish 
redirection of the traffic that flows through routers. 

This chapter contains the following topics: 

□ Section A: "Understanding Forwarding" on page 92 

□ Section B: "Configuring Forwarding through the CLI" on page 94 

□ Section C: "Using Forwarding Directives to Create an Installable List" on page 104 

□ Section D: "TCP Connection Forwarding" on page 111 



Note: Forwarding (TCP Connection Forwarding excluded) is configured through 

the CLI or through installable lists using directives. The CLI and the directives have 
been designed to be as similar as possible; the functionality is identical. 
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Section A: Understanding Forwarding 

The SG appliance forwarding system allows you to represent what the upstream network 
looks like to the appliance at the level of the Web addresses (URLs). Forwarding is not 
concerned with the packet addressing associated with networking equipment, such as 
switches, routers, and hubs. Fonvarding allows you to send Web requests to something 
other than the IP address specified in the URL and organize how the Web traffic flows 
around the network. 

The SG appliance forwarding system encompasses the use of forwarding, upstream 
SOCKS gateways, load balancing, host affinity, health checks, and ICP. The SG appliance 
forwarding system determines the upstream address a request is sent to and is 
fundamentally tied in with all of the protocol agents, including HTTP, HTTPS, streaming, 
and FTP, and the network configuration. The combination of forwarding with the policy 
engine allows extremely flexible configuration and traffic management. 



Note: The SG appliance forwarding system is available for HTTP, HTTPS, FTP, Windows 
Media, RTSP, Telnet, and TCP tunnels. 



Understanding Load Balancing 

Load balancing is a way to share traffic requests among multiple upstream systems or 
multiple IP addresses on a single host. Technologies used include round robin, which 
selects the next system in the list, or least-connections, which selects the system with the 
least number of connections among the selected group. 

You can configure load balancing several ways: 

□ For individual hosts: If a host is DNS-resolved to multiple IP addresses, then that 
host's load balancing method (round-robin, least connections, or none) is applied to 
those IP addresses. The method is either explicitly set for that host or taken from the 
configurable global default settings. 

□ For groups, two load balancing choices are available: 

• Apply a load-balancing method to a group. The hashing option must be 
specifically disabled (it is enabled by default) before you can apply the load 
balancing method to a group. Without using a hash, all the IP addresses of all the 
members of the group are gathered together, and the group's method is applied 
across that entire set of IP addresses. 

• Use a hash. If you use a hash, load balancing is a two-step process: 

• Step one: Apply a hash, either to the domain name or the full URL. This hash 
value is used to select one member of the group. 

• Step two: The selected host is treated just as an individual host is treated; the 
only difference is that the load-balancing method configured for the group is 
used for the selected host. 

For more information, see "Configuring Load Balancing" on page 99. 
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Understanding Host Affinity 

Host affinity is the attempt to direct multiple connections by a single user to the same 
group member. For example, a Web site uses shopping carts to allow customers to purchase 
items. The site might use load balancing with a group of Web servers working in parallel, 
but only one server in the group has state on a single user. If the user connections are sent 
to a different server, the server has no previous state on the user and might start over. 

Host affinity forces the user 's connections to return to the same server until the user is idle 
for a configurable period of time. After a configurable period of inactivity, the host affinity 
times out and the fact that multiple connections belong to a single user is lost. 

Host affinity allows you to use any of the following options: 

□ Use the client IP address to determine which group member was last used. When the 
same client IP sends another request, the connection is made to that recorded group 
member. 

□ Place a cookie in the response to the client. When further requests are sent from the 
client with the cookie, the data in the cookie is used to determine which group member 
the client last used. The connection is made to that recorded group member. 

□ For HTTPS, extract the SSL session ID name from the connection information. The 
session ID is used in place of a cookie to determine which group member was last 
used. The connection is made to that recorded group member. 

For more information on host affinity, see "Configuring Host Affinity" on page 100. 

Using Load Balancing and Host Affinity Together 

By default, if you use load balancing, each connection is treated independently. That 
connection is made to whichever member of the load-balancing group that the load- 
balancing algorithm selects. The load balancing responsibility is to spread the connections 
around as much as possible so the load is shared among group members. 

If host affinity is configured, it is checked first to see if the request comes from a known 
client. If this is a first connection, the load-balancing algorithm selects the group member 
to target. The result of the load balancing is recorded by host affinity in its tables for use if 
that client connects again. 

Host affinity does not make a connection to a host that health checks report is down; 
instead, if host affinity breaks, the load-balancing algorithm selects a group member that 
is healthy, and affinity is re-established on that working group member. 

For information on configuring host affinity, see "Configuring Host Affinity" on page 100; 
for information on configuring load balancing, see "Configuring Load Balancing" on page 
99. 
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Section B: Configuring Forwarding through the CLI 

Forwarding is configured through the CLI or through installable lists using directives. The 
CLI and the directives have been designed to be as similar as possible; the functionality is 
identical. To use installable lists to configure forwarding, see Section C: "Using 
Forwarding Directives to Create an Installable List" on page 104. 

High level steps to configure forwarding are: 

□ Create the forwarding hosts and groups, including parameters such as protocol agent 
and port 

□ Edit these hosts and groups; you can create settings that override the global defaults 

□ Create Load Balancing and Host Affinity values 

Creating Forwarding Hosts and Groups 

You can create a maximum of 32 groups, and each group can contain a maximum of 512 
hosts. You can create 512 individual hosts that do not belong to any group. (You might 
want to create individual hosts as a way of managing traffic inside an enterprise, for 
example.) 

The only required entries under the create command (for a host) are the host_alias, 
hostname, a protocol, and a port number. The port number can be defined explicitly (such 
as http= 808 o), or it can take on the default port value of the protocol, if one exists (such as 
http, and the default port value of 8 0 is entered automatically). 



Note: The host/ group aliases cannot be CPL keywords, such as no, default, or 
forward. 



To create a host group, you must also include the group=group_name option. If this is the 
first mention of the group, group_name, then that group is automatically created with this 
host as its first member. Do not use this command when creating an independent host. 

Because the functionality of the CLI and the directives is so similar, detailed instructions 
are provided only for the CLI. For the list of available directives, see "Using Forwarding 
Directives to Create an Installable List" on page 104. 

To create the host or group: 

1. At the (conf ig) command prompt, create a forwarding host: 

SGOS# (conf ig) forwarding 

SGOS# (config forwarding) create host_alias hostname [default-schemes] 
[http[=port | =no] ] [https [=port | =no] ] [ftp[=port | =no] ] [mms [=port 
| =no] ] [rtsp[=port | =no] ] [tcp=port] [telnet [=port | =no] ] [ssl- 
verify-server [=yes | =no] ] [group=group_name] [server | proxy] [load- 
balance^ no | round-robin | least-connections } ] [host-af f inity= {no | 
client-ip-address | accelerator-cookie}] [host-aff inity-ssl={no | 
client-ip-address | accelerator-cookie | ssl-session-id} ] 
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Table 7-1 . Commands used to Create a Forwarding Host 



Command 


Suboption 


Description 


host_alias 




This is the alias for use in policy. Define a meaningful 
name. 


host_name 




The name of the host domain, such www . bluecoat . com, 
or its IP address. 


default-schemes 




If you select default - schemes, all protocols, along with 
their default ports, are used. This directive is only 
available for proxy hosts. 


http 

https 

ftp 

mms 

rtsp 

telnet 


=port | =no 


You must choose at least one protocol where port=l to 
6553 5. If only one protocol is configured, the SG 
configures the default port for that protocol. 

You can use default -schemes and then eliminate 
protocols by selecting the protocol you do not want; for 
example, http=no. If you do not want to use the default 
ports for the protocols, you must also specify them here. 
HTTPS or Telnet protocols are not allowed if the host is a 
proxy. 


tcp 


=port 


If you choose to add a TCP protocol, a TCP port must be 
specified. 

TCP protocols are not allowed if the host is a proxy. 


ssl-verify-server 


=yes | =no 


You can set SSL to specify that the SG appliance checks the 
CA certificate of the upstream server. 

The default for ssl-verify-se rve r is ye s . To disable 
this feature, you must specify ssl-verify-server=no 
in the installable list or CLI. 

Note that the CPL property 

server . certificate .validate , if configured, 
overrides this setting. 


group 


=group_name 


Group specifies the group to which this host belongs. If 
this is the first mention of the group group name then 
that group is automatically created with this host as its 
first member. 

The SG appliance uses load balancing to evenly distribute 
forwarding requests to the origin servers or group of 
proxies. Do not use the group= option when creating 
independent hosts. 


server | proxy 




Server specifies to use the relative path for URLs in the 
HTTP header because the next hop is a Web server, not a 
proxy server. The default is proxy. 


load-balance 


no | round-robin [ least- 
connections 


Specifies the load-balancing method: round robin or least 
connections. No disables load balancing. 


host-affinity 


accelerator-cookie | client- 
ip-address | no 


Specifies which non-SSL host-affinity method to use 
(accelerator cookie or client-ip-address) or 
you can use no to disable non-SSL host affinity. 
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Table 7-1. Commands used to Create a Forwarding Host (Continued) 



Command 


Suboption 


Description 


host-affinity-ssl 


accelerator-cookie | client- 
ip-address | ssl-session-id | 
no 


Specifies which SSL host-affinity method to use 
(accelerator cookie, client-ip-address, or ssl- 
session-id) or you can use no to disable SSL host 
affinity. 



2 . 

3. 



Repeat Step 1 to create additional forwarding hosts or host groups. 



Complete the configuration by entering the following commands as necessary: 



SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
host_alias} 
SGOS# (config 
SGOS# (config 



forwarding) 

forwarding) 

forwarding) 

forwarding) 

forwarding) 

forwarding) 



download-via- forwarding disable | enable 
failure-mode closed | open 
integrated-host-timeout minutes 
delete {all | group group_name | host 

path url 
no path 



Table 7-2. Commands used to Configure a Forwarding Host 



Command 


Suboption 


Description 


download-via-forwarding 


enable | disable 


Specifies whether forwarding (and SOCKS gateways) are to 
be used or ignored when trying to download or upload 
documents, including installable lists and policy files. 


failure-mode 


closed | open 


Failing open or closed applies to forwarding hosts and 
groups. Fail Open/ Closed applies when the health checks 
are showing sick for each forwarding target in the applicable 
fail-over sequence. If no systems are healthy, the SG 
appliance fails open or closed, depending on the 
configuration. If closed, the connection attempt simply fails. 






If open, an attempt is made to connect without using any 
forwarding target. Fail open is usually a security risk; fail 
closed is the default if no setting is specified. 

This setting can be overridden by policy, (using the 
forward, fail open (yes | no) property). 


integrated-host-timeout 


minutes 


An integrated host is an Origin Content Server (OCS) that 
has been added to the health check list. The host, added 
through the integrate new hosts property, ages out 
after being idle for the specified time. The default is 60 
minutes. 


delete 


all | group 
groupjname | host 
host_alias 


Deletes all forwarding hosts and groups (delete all) or a 
specific forwarding group (delete group group name) 
or host (delete host host_al ias). 


path 


url 


(Optional) Path specifies the download path to use if you 
download installable lists. 


no 


path 


No clears the network path URL to download forwarding 
settings. 
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Editing a Forwarding Host 

After you create a forwarding host, you can edit its configuration. 



Note: If you edit a group, you can only modify its load balancing and host affinity 
settings. For information on editing a group, see "Editing a Forwarding Group" on page 



99. 



To edit the settings of a forwarding host: 

1. At the (config) command prompt, enter the following commands to configure the 
settings of a forwarding host: 

SGOS# (config) forwarding 

SGOS# (config forwarding) edit host_alias 

SGOS# (config forwarding host_alias) {ftp | http | https | mms | rtsp | 
telnet} [port] 

SGOS# (config forwarding host_alias) group group_name 
SGOS# (config forwarding host_alias) host hostname 
SGOS# (config forwarding host_alias ) host-affinity {method 
{accelerator-cookie | client-ip-address | default} | ssl-method 
{accelerator-cookie | client-ip-address | ssl-session-id | default} 
SGOS# (config forwarding host_alias ) load-balance method {least- 
connections | default | round-robin} 

SGOS# (config forwarding host_alias) proxy | server 
SGOS# (config forwarding host_alias ) ssl-verify-server 
SGOS# (config forwarding host_alias) tcp port 



Table 7-3. Commands Used to Edit a Forwarding Host 



Command 


Suboption 


Description 


ftp | http | 
https | mms | 
rtsp | telnet 


[port] 


Adds the protocol and optional port for this host if it 
was not set previously or changes the port number for 
the specified protocol if it was. If you do not enter a port 
number, the default port number is used. 

HTTPS or Telnet protocols are not allowed if the host is 
a proxy. 


tcp 


port 


Changes the port number for the TCP protocol for this 
host. You must enter a port number if you use the TCP 
protocol. 

TCP protocols are not allowed if the host is a proxy. 


group 


group name 


Changes the group membership for this host. 


host 


host name 


Changes this host's name. 


host-af f inity 


method (accelerator- 
cookie | client-ip- 
address | default) 


Sets which non-SSL host-affinity method to use 
(accelerator cookie or client-ip-address) or 
you can use default to specify the global method. 


ssl-method (accelerator- 
cookie | client-ip- 
address | ssl-session-id 
| default} 


Sets which SSL host-affinity method to use 
(accelerator cookie, client-ip-address, or 
ssl-session-id) or you can use default to specify 
the global method. 
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Table 7-3. Commands Used to Edit a Forwarding Host (Continued) 



Command 


Suboption 


Description 


load-balance 

method 


least-connections | 
round- robin | default 


Allows you to select the round-robin method or the 
least-connections method, or specify default to 
specify the global method. 


proxy 




Defines this host as a proxy instead of a server; any 
HTTPS, Telnet, or TCP port is deleted. 


server 




Defines this host as a server instead of a proxy. 


ssl -verify- server 




Sets SSL to specify that the SG appliance checks the CA 
certificate of the upstream server for this host. 



2. (Optional) Enter the following commands to negate or disable settings for this host 
(only one setting can be negated at a time): 

SGOS# (config forwarding host_alias ) no {ftp | http | https | irons | rtsp 
| top | telnet} 

-or- 

SGOS# (config forwarding host_alias ) no group 
-or- 

SGOS# (config forwarding host_alias ) no host-affinity (method ] ssl- 
method} 

-or- 

SGOS# (config forwarding host_alias ) no load-balance method 
-or- 

SGOS# (config forwarding host_alias ) no ssl -verify- server 



Table 7-4. Commands to Negate Forwarding Host Settings 



Command 


Suboption 


Description 


no {ftp | http | https | mms | 
rtsp | tcp | telnet} 




Clears the specified protocol and port 
from this host. 


no group 




Removes this host from any and all 
groups. 


no host-affinity 


method | ssl-method 


Clears the specified method from this 
host. 


no load-balance 


method 


Clears the method from this host. 


no ssl-verify-server 




Disables SSL verification for this host. 



Example 

SGOS# (config) forwarding 
SGOS# (config forwarding) edit testhost 
SGOS# (config forwarding testhost) server 
ok 

SGOS# (config forwarding testhost) no ftp 
ok 

SGOS# (config forwarding testhost) exit 
SGOS# (config forwarding) exit 
SGOS# (config) 



98 



Chapter 7: Configuring the Upstream Networking Environment 



Section B: Configuring Forwarding through the CLI 



Editing a Forwarding Group 

When you edit a group, you can change the load-balance and host-affinity settings. 

To edit a group: 

At the (config) command prompt, enter the following commands to configure the 
settings of a forwarding host: 

SGOS# (config) forwarding 

SGOS# (config forwarding) edit group_alias 

SGOS# (config forwarding group_alias ) host-affinity {method 
{accelerator-cookie | client-ip-address | default} | ssl-method 
{accelerator-cookie | client-ip-address | ssl - session- id | default} 
SGOS# (config forwarding group_alias) load-balance hash {domain | no | 
url } 

SGOS# (config forwarding group_alias) load-balance method {least- 
connections | default | round-robin} 



Table 7-5. Commands to Edit a Forwarding Group 



Command 


Suboption 


Description 


host-affinity 


method (accelerator-cookie | 
client-ip-address | default) 


Sets which non-SSL host-affinity method to use 
(accelerator cookie or client-ip- 
address) or you can use default to specify 
the global method. 


ssl-method (accelerator- 
cookie | client-ip-address | 
ssl-session-id | default} 


Sets which SSL host-affinity method to use 
(accelerator cookie, client-ip- 
address, or ssl-session-id) or you can use 
default to specify the global method. 


load-balance 


hash {domain | default | 
url } 


If you use the hash for load balancing, you can 
choose to hash the domain or the full URL or you 
can use default to disable hashing, and the 
load balancing method applies across a group. 
Hash is enabled by default. 


method {least-connections | 
round-robin | default} 


If you use method for load balancing, you can 
select the round-robin method or the least- 
connections method, or specify default to specify 
the global method. 



Configuring Load Balancing 

Load balancing settings can be configured globally (for all forwarding hosts and groups), 
or load balancing can be configured to a host or group's private values. These private 
values override the global default settings. (For an overview of load balancing, see 
"Understanding Load Balancing" on page 92.) 

To set load balancing global default settings: 

SGOS# (config) forwarding 

SGOS# (config forwarding) load-balance hash {domain | no | url} 

SGOS# (config forwarding) load-balance method {least-connections | no | 
round- robin} 
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Table 7-6. Commands to Set Load Balancing Global Default Settings 



Command 


Suboption 


Description 


hash 


{domain | no | url} 


If you use the hash for load balancing, you can choose to hash the 
domain or the full URL or no to disable hashing, and the load 
balancing method applies across a group. Hash is enabled by default. 


method 


{least-connections | no 
| round- robin} 


If you use method for load balancing, you can select the round-robin 
method or the least-connections method, or specify no to disable load 
balancing. 



Note: Remember that a group must have a hash setting of no in order for the method to 
apply across the entire group. 



To set load balancing private values: 

SGOS# (config) forwarding 

SGOS# (config forwarding) load-balance hash {default | domain | no | 
url} group_alias 

SGOS# (config forwarding) load-balance method {default | least- 
connections | no | round-robin} host_or_group_alias 



Table 7-7. Commands to Set Load Balancing Private Values 



Command 


Suboption 


Description 


hash 


{default | domain | no | url} 
group_alias 


You can specify a group to apply the load-balancing hash 
setting to only that group. Hashing is enabled by default. 


method 


{default | least-connections | 
no | round- robin} 
host or group alias 


You can specify a host or group to apply the load- 
balancing method to only that host or group. 



Example 

SGOS# (config forwarding) load-balance method least-connections test- 
host-name 
ok 

Configuring Host Affinity 

Host affinity settings can be configured globally (for all forwarding hosts and groups), or 
the settings can be configured fort a host or group's private values. These private values 
override the global default settings. (For an overview of host affinity, see "Understanding 
Host Affinity" on page 93.) 

The non-SSL host affinity methods are implemented for HTTP only; SSL host affinity 
methods are implemented for HTTPS only. 
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To configure global default host affinity settings: 

SGOS# (config) forwarding 

SGOS# (config forwarding) host-affinity method {accelerator-cookie | 
client-ip-address | no} 

-or- 

SGOS# (config forwarding) host-affinity ssl-method {accelerator-cookie 
| client-ip-address | ssl-session-id | no} 

SGOS# (config forwarding) host-affinity timeout minutes 

where: 



method 


{accelerator-cookie | 
client-ip-address | no} 


Sets which non-SSL host-affinity 
method to use (accelerator cookie 
or client-ip-address) or you can 
use no to disable non-SSL host affinity. 


ssl-method 


{accelerator-cookie | 
client-ip-address | ssl- 
session-id | no} 


Sets which SSL host-affinity method to 
use (accelerator cookie, client- 
ip -address, or ssl-session-id) or 
you can use no to disable SSL host 
affinity. 


timeout 


minutes 


Determines how long a user's IP 
address, SSL ID, or cookie remains 
valid. 



To configure host- or group-specific host affinity settings: 

SGOS# (config) forwarding 

SGOS# (config forwarding) host-affinity method {accelerator-cookie | 

client-ip-address | default | no} host_or_group_alias 

-or- 

SGOS# (config forwarding) host-affinity ssl-method {accelerator-cookie 

I 

client-ip-address | default | no} host_or_group_alias 



Table 7-8. Commands to Configure Host- or Group-Specific Host Affinity Settings 



Command 


Suboptions 


Description 


method 


{accelerator-cookie | 
client-ip-address | 
default | no} 
host_or_group_alias 


You can choose which non-SSL host-affinity method to use 
(accelerator cookie or client-ip-address) for a 
specific host or group, or you can use no to disable non-SSL 
host affinity for a specific host or group. You can also apply 
the global non-SSL host-affinity method to a specific host or 
group. 


ssl_method 


{accelerator-cookie | 
client-ip-address | 
default | no | ssl- 
session-id} 
host_or_group_alias 


You can choose which SSL host-affinity method to use 
(accelerator cookie, client-ip-address, or ssl- 
session-id) for a specific host or group, or you can use no 
to disable SSL host affinity for a specific host or group. You 
can also apply the global SSL host-affinity method to a 
specific host or group (use the default command). 
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Example 

SGOS# (conf ig forwarding) host-affinity method client- ip-address 

ok 

SGOS# (conf ig forwarding) host-affinity ssl-method no test -group -name 
ok 

SGOS# (conf ig forwarding) host-affinity timeout 45 
ok 

Creating a Default Sequence 

The default sequence defines the order in which forwarding hosts are used in case of 
failover and which host to use first (only one default sequence is allowed). If you create a 
default sequence, forwarding is applied, by default, to all requests. All members must be 
pre-existing hosts and groups, and no member can be in the group more than once. 



Note: Creating a default sequence through the CLI is a legacy feature. Creating a default 
sequence can be done much more efficiently through policy — VPM or CPL — than it can 
through the CLI. The default sequence (if present) is applied only if no applicable 
forwarding gesture is in policy. 

For information on using VPM, refer to Volume 7: VPM and Advanced Policy ; for 
information on using CPL, refer to Volume 11: Content Policy Language Guide. For 
information on using forwarding with policy, see Appendix B: "Using Policy to Manage 
Forwarding" on page 207. 



A default failover sequence (and any sequence specified in policy) works by allowing 
healthy hosts to take over for an unhealthy host (one that is failing its DNS Resolution or 
its health check). The sequence specifies the order of failover, with the second host taking 
over for the first host, the third taking over for the second, and so on. 



Note: In normal circumstances, only the first member of the sequence is ever used. 



If all hosts are unhealthy, the operation fails either open or closed, depending upon your 
settings. 

This configuration is generally created and managed through policy. If no forwarding 
policy applies, you can create a default sequence through the CLI. This single default 
sequence consists of a single default host (or group) plus one or more hosts to use if the 
preceding ones are unhealthy. 



To create a default sequence: 

From the (config) prompt, enter the following commands: 



SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



forwarding) 

forwarding) 

forwarding) 

forwarding) 

forwarding) 



sequence 

sequence 

sequence 

sequence 

sequence 



add alias_name 

clear 

demote alias_name 
promote alias_name 
remove alias name 



Table 7-9. Commands to Create a Default Sequence 



Command 


Suboptions 


Description 


add 


alias name 


Adds an alias to the end of the default failover sequence. 
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Table 7-9. Commands to Create a Default Sequence (Continued) 



Command 


Suboptions 


Description 


clear 




Clears the default failover sequence. 


demote 


alias name 


Moves an alias one place towards the end of the default failover 
sequence. 


promote 


alias name 


Moves an alias one place towards the start of the default failover 
sequence. 


remove 


alias name 


Removes an alias from the default failover sequence. 



Example 

SGOS# (config forwarding) sequence clear 
ok 



Note: Any host or group in the default sequence is considered in use by policy. As a 
result, if you try to delete a host or group while it is in the default sequence, you receive an 
error message. You must remove the host/ group from the sequence first, then delete. 
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Section C: Using Forwarding Directives to Create an Installable List 

You can use either directives or the CLI #inline forwarding command to create and 
configure forwarding hosts. To use the CLI to configure forwarding hosts, see Section A: 
"Understanding Forwarding" on page 92. 

The forwarding configuration includes directives that: 

□ Create the forwarding hosts and groups 

□ Provide load balancing and host affinity 



Table 7-10. Forwarding Directives 



Directive 


Meaning 


See 


fwd fail 


Determines whether the forwarding host 
should fail open or fail closed if an operation 
does not succeed. Fail open is a security risk. 


"Setting Fail Open/ Closed and 
Host Timeout Values" on page 
106. 


fwd_host 


Create a forwarding host and set 
configuration parameters for it, including 
protocols and ports. 


"Creating Forwarding Host and 
Group Directives" on page 104. 


host affinity 


The attempt to direct multiple connections by 
a single user to the same group member. 


"Configuring Host Affinity 
Directives" on page 107. 


integrated host 
timeout 


An origin content server that has been added 
to the health check list is called an integrated 
host. The host ages out after being idle for the 
specified time. 


"Setting Fail Open/ Closed and 
Host Timeout Values" on page 
106. 


load balance 


The attempt to manage the load among 
forwarding hosts in a group, or among 
multiple IP addresses of a host. 


"Configuring Load Balancing 
Directives" on page 107. 


sequence alias_list 


where alias list is a space separated list 
of one or more forwarding host and group 
aliases. 


"Creating a Default Sequence" on 
page 108. 



Creating Forwarding Host and Group Directives 

You can add directives into the forwarding installable list that allows you to create and 
delete the forwarding host and associate protocols and ports with the host. 

You can create a maximum of 32 groups, and each group can contain a maximum of 512 
hosts. You can create 512 individual hosts that do not belong to any group. 

To create a forwarding host, choose the protocols you want to use, or optionally add the 
forwarding host to a group, enter the following into your installable list. Create a 
fwd_host directive for each forwarding host you want to create. 

fwd_host host_alias hostname [default-schemes] [http [=port | =no] ] 
[https [=port | =no] ] [ftp[=port | =no] ] [rams [=port | =no] ] [rtsp [=port 
| =no] ] [tcp=port] [telnet [=port | =no] ] [ssl-verify-server [=yes | 

=no] ] [group=group_name] [server | proxy] [load-balance= {no [ round- 
robin | least-connections}] [host-aff inity={no | client-ip-address | 
accelerator-cookie}] [host-aff inity-ssl= {no | client-ip-address | 
accelerator-cookie | ssl - session- id} ] 
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Table 7-1 1 . Commands to Create Forwarding Host and Group Directives 



host_alias 




This is the alias for use in policy. Define a name meaningful to 
you. 


host name 




The name of the host domain, such www . bluecoat . com, or its 
IP address. 


default -schemes 




If you use default-schemes in the directive, all protocols, along 
with their default ports are selected. This directive is only 
available for proxy hosts. 


http 

https 

ftp 

mms 

rtsp 

telnet 


=port | =no 


No protocol is selected by default if the forwarding host is a 
server. You must choose at least one protocol where port=0 to 
6 5 5 3 5 . If only one protocol is configured, the SG configures the 
default port for that protocol. 

You can use default - schemes and then eliminate protocols 
by selecting the protocol you do not want; for example, 
http=no. If you do not want to use the default ports for the 
protocols, you must also specify them here. 

HTTPS protocols are not allowed if the host is a proxy. 


tcp 


=port 


If you choose to add a TCP protocol, a TCP port must be 
specified. 

TCP protocols are not allowed if the host is a proxy. 


ssl -verify- 
server 


=yes | =no 


Sets SSL to specify that the SG appliance checks the CA 
certificate of the upstream server. 

The default for ssl-verify-server is yes. To disable this 
feature, you must specify ssl -verify- server=no in the 
installable list or CLI. In other words, you can configure ssl- 
verify-server=yes in three ways: do nothing (yes is the 
default), specify ssl-verify-server, or specify ssl- 
verify-server=yes . 


group 


=group name 


Specifies the group (or server farm or group of proxies) to 
which this host belongs. If this is the first mention of the group 
group name then that group is automatically created with this 
host as its first member. 

The SG appliance uses load balancing to evenly distribute 
forwarding requests to the origin servers or group of proxies. 
Do not use the group= option when creating independent 
hosts. 


server | proxy 




server specifies to use the relative path for URLs in the HTTP 
header because the next hop is a Web server, not a proxy server. 
The default is proxy. 
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Table 7-1 1 . Commands to Create Forwarding Host and Group Directives (Continued) 



load-balance 


=no | = round- robin | 
= least -connect ions 


Specifies either the least-connections or round-robin method of 
load balancing. Select no to disable load balancing for this 
forwarding host or host group. 

If these settings are not specified for a particular host or host 
group, then the global default settings are used. To configure 
the settings for a specific host or host group, use the edit 
host alias or edit group alias commands (see "Editing 
a Forwarding Host" on page 97 or "Editing a Forwarding 
Host" on page 97). 


host-af f inity 


=no | =client-ip- 
address | 

=accelerat or -cookie 


Specifies non-SSL host affinity via either a client IP address or 
an accelerator cookie. Select no to disable non-SSL host affinity 
for this forwarding host or host group. 

If these settings are not specified for a particular host or host 
group, then the global default settings are used. To configure 
the settings for a specific host or host group, use the edit 
host alias or edit group alias commands (see "Editing 
a Forwarding Host" on page 97 or "Editing a Forwarding 
Group" on page 99). 


host-af f ini ty- 
ssl 


=no | =client-ip- 
address | 

=accelerat or -cookie 
| =ssl-session-id 


Specifies SSL host affinity via a client IP address, an accelerator 
cookie, or an SSL session ID. Select no to disable SSL host 
affinity for this forwarding host or host group. 

If these settings are not specified for a particular host or host 
group, then the global default settings are used. To configure 
the settings for a specific host or host group, use the edit 
host_alias or edit group_alias commands (see "Editing 
a Forwarding Host" on page 97 or "Editing a Forwarding 
Group" on page 99). 



Example 

fwd_host www.bluecoatl.com 10.25.36.48 default-schemes ssl-verify- 
server=no group=bluecoat 

Setting Fail Open/Closed and Host Timeout Values 

Using directives, you can determine if the forwarding host fails open or closed, if an 
operation does not succeed, and the interval it takes for integrated hosts to be aged out. 

An integrated host is an Origin Content Server (OCS) that has been added to the health 
check list. If the policy property integrate_new_hosts applies to a forwarding request, 
the SG appliance makes a note of each OCS and starts health checking to help future 
accesses to those systems. If the host is idle for the interval you specify, it is aged out. Sixty 
minutes is the default. 

The syntax is: 

fwd_fail {open | closed} 
integrated_host_timeout minutes 
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Table 7-12. Commands to Set Fail Open/Closed and Host Timeout Values 



fwd fail 


{open | 
closed} 


Determines whether the forwarding host should fail open 
or fail closed if an operation does not succeed. Fail open is a 
security risk, and fail closed is the default if no setting is 
specified. 

This setting can be overridden by policy, (using the 
forward, fail open (yes | no) property). 


integrated host timeout 


minutes 


An OCS that has been added to the health check list is called 
an integrated host. The host ages out after being idle for the 
specified time. 



Examples 

fwd_fail open 
integrated_host_timeout 90 

Configuring Load Balancing Directives 

Load balancing shares the load among a set of IP addresses, whether a group or a host 
with multiple IPs. 

The syntax is: 

load_balance hash {domain [ no | url} [ group_alias ] 
load_balance method {least-connections [ round-robin | no} 

[ hos t_ or_group_ alias ] 



Table 7-13. Load Balancing Directives 



Command 


Suboptions 


Description 


hash 


{domain | no | url} 
[ group_alias ] 


If you use the hash for load balancing, you can hash the domain 
or the full URL, or you can enter no to disable hashing and the 
load-balancing method applies across a group. If you do not 
specify a group, the settings apply as the default for all groups. 


method 


{least-connections | no | 
round-robin} 

[ host_or_group_alias ] 


If you use method for load balancing, you can select the 
least-connections method or the round- robin method, 
or you can specify no to disable load balancing (hashing still 
occurs if it is set). If you do not specify a host or group, the 
settings apply as the default for all hosts or groups. 



Example 

load_balance method least_connections 

Configuring Host Affinity Directives 

Host affinity is the attempt to direct multiple connections by a single user to the same 
group member. 

The syntax is: 

host_af f inity method {accelerator-cookie | client-ip-address | no} 

[ hos t_ or_group_ alias ] 

host_aff inity ssl_method {accelerator-cookie | client-ip-address | no 
| ssl-session-id} [ host_or_group_alias ] host_aff inity timeout seconds 
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Table 7-14. Commands to Configure Host Affinity Directives 



Command 


Suboption 


Description 


method 


{accelerator-cookie | 
client-ip-address | no} 
[ host_or_group_al ias ] 


Determines which non-SSL host-affinity method to use 
(accelerator cookie or client- ip -address), or you 
can use no to disable non-SSL host affinity. If you do not 
specify a host or group, the settings apply as the default for all 
hosts or groups. 


ssl_method 


{accelerator-cookie | 
client-ip-address | no | 
ssl- session- id} 
[host_or_group_al ias] 


Determines which SSL host-affinity method to use 
(accelerator cookie, client-ip-address, or ssl- 
session- id), or you can use no to disable SSL host affinity. If 
you do not specify a host or group, the settings apply as the 
default for all hosts or groups. 


timeout 


minutes 


Determines how long a user's IP address, SSL ID, or cookie 
remains valid. 



Example 

host_af f inity ssl_method 10.25.36.48 
host_af f inity timeout 5 

Creating a Default Sequence 

A default sequence defines the order in which forwarding hosts are used. Only one 
default sequence is allowed. All members must be pre-existing hosts and groups, and no 
member can be in the group more than once. 



Note: The default sequence is completely overridden by policy. 



A default failover sequence works by allowing healthy hosts to take over for an unhealthy 
host (one that is failing its DNS Resolution or its health check). The sequence specifies the 
order of failover, with the second host taking over for the first host, the third taking over 
for the second, and so on). 

If all hosts are unhealthy, the operation fails either open or closed, depending upon your 
settings. 

This configuration is generally created and managed through policy. If no forwarding 
policy applies, you can create a default sequence through the CLI. This single default 
sequence consists of a single default host (or group) plus one or more hosts to use if the 
preceding ones are unhealthy. 

The syntax is: 

sequence alias_list alias_list 

where alias_list is a space-separated list of one or more forwarding host and group 
aliases. 

Example 

sequence bluecoat 
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Creating a Forwarding Installable List 

You can create and install the forwarding installable list using one of the following 

methods: 

□ Text Editor, which allows you to enter the installable list of directives (or copy and 
paste the contents of an already-created file) directly onto the appliance. 

□ A local file, created on your system; the SG appliance can browse to the file and install 
it. 

□ A remote URL, where you placed an already-created file on an FTP or HTTP server to 
be downloaded to the SG appliance. 

□ CLI inline command. 

When the Forwarding Installable List is installed, it updates the forwarding directives on 

the SG appliance. The directives remain in effect until they are overwritten by another 

installable list; the list can be modified or overwritten using CLI commands. 



Note: During the time that a forwarding installable list is being compiled and installed, 
forwarding is not available. Any transactions that come into the SG appliance during this 
time are not forwarded properly and are denied. 



Installation of forwarding installable lists should be done outside peak traffic times. 

To create a forwarding installable list: 

1. Select Configuration > Forwarding > Forwarding Hosts. 

2. From the drop-down list, select the method to use to install the forwarding installable 
list; click Install. 



Note: A message is written to the event log when you install a list through the SGOS 
software. 



• Remote URL: 

Enter the fully-qualified URL, including the filename, where the installable list is 
located. To view the file before installing it, click View. Click Install. Examine the 
installation status that displays; click OK. 

• Local File: 

Click Browse to display the Local File Browse window. Browse for the installable 
list file on the local system. Open it and click Install. When the installation is 
complete, a results window opens. View the results, close the window, click Close. 

• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the installation is 
complete, a results window opens. View the results, close the window, click Close. 



Note: The Management Console text editor is a way to enter an installable list 
for forwarding. It is not a way to enter CLI commands. The directives are 
understood only by the installable list parser for forwarding. 
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3. Click Apply. 



Note: You can create forward settings using the CLI #inline forwarding command. 
You can use any of the forwarding directives, but host affinity and load balancing are 
mutually exclusive. 

For more information on using inline commands, refer to Volume 12: Command Line 
Reference : "Chapter 2: Standard and Privileged Commands". 



To delete forwarding settings on the SG appliance: 

From the (conf ig) prompt, enter the following commands to delete a host, a group, or 
all hosts and groups from the forwarding configuration: 

SGOS# (config) forwarding 

SGOS# (config forwarding) delete {all | group group_name | host 
host_alias} 



Note: Any host or group in the default sequence is considered in use by policy. As a 
result, if you try to delete a host or group while it is in the default sequence, you receive an 
error message. You must remove the host/ group from the sequence first, then delete. 
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Section D: TCP Connection Forwarding 

This section describes how to configure the SG appliance to join peer clusters that process 
requests in asymmetrically routed networks. 



About Asymmetric Routing Environments 

It is common in larger enterprises to have multiple SG appliances residing on different 
network segments; for example, the enterprise receives Internet connectivity from more 
than one ISP. If IP spoofing is enabled, connection errors can occur because the SG 
appliance terminates client connections and makes a new outbound connection (with the 
source IP address of the client) to the server. The response might not return to the 
originating SG appliance, as illustrated in the following diagram. 




SG 1 
Reflect 
client IP 





Flow: 

1: The client makes a request; SG appliance 1 (SG 1) intercepts the connection. 

2. SG 1 terminates the client connection and invokes an oubound connection to the server 
(with the source IP address of the client). 

3. Based on its internal routing policies, the server believes ISP 2 provides a viable path back to 
the client. 

4. SG 2 intercepts the response with the originating client IP address; however, it does not 
recognize the connection from the client and attempts to reset the connection. 

5. The client connection ultimately times out and the client receives connection timeout error. 



Figure 7-1 . Multiple SG appliances in an asymmetric routing environment 



The TCP Connection Forwarding Solution 

Enabling TCP Connection Forwarding is a critical component of the following solutions: 
□ "About Bidirectional Asymmetric Routing" on page 112. 
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□ "About Dynamic Load Balancing" on page 113. 

□ "About ADN Transparent Tunnel Load Balancing" on page 113. 

About Bidirectional Asymmetric Routing 

To solve the asymmetric routing problem, at least one SG appliance on each network 
segment must be configured to perform the functionality of an L4 switch. These selected 
appliances form a cluster. With this peering relationship, the connection responses are 
able to be routed to the network segment where the originating client resides. 

In the 5.1.4.x release, cluster membership is manual; that is, SG appliances must be added 
to a cluster by enabling connection forwarding and adding a list of other peers in the 
cluster. After a peer joins a cluster, it begins sending and receiving TCP connections, and 
notifies the other peers about its connection requests. 




Flow: 

1 : The client makes a request; SG appliance 1 (SG 1 ) intercepts the connection. 

2: Because SG 1 and SG 2 are peers in the TCP forwarding cluster, SG 1 informs SG 2 
about the connection request. 

3: SG 1 terminates the client connection and invokes an oubound connection to the server 
(with the source IP address of the client). 

4: Based on its internal routing policies, the server believes ISP 2 provides a viable path 
back to the client. 

5: SG 2 intercepts the response with the originating client IP address. 

6: SG 2 routes the response back up to the internal network. 

7: SG 1 receives the response and serves the client. 



Figure 7-2. SG appliances share TCP connection information 



112 



Chapter 7: Configuring the Upstream Networking Environment 



Section D: TCP Connection Forwarding 



About Dynamic Load Balancing 

In a deployment where one SG appliance receives all of the traffic originating from clients 
and servers from an external routing device and distributes connections to other SG 
appliances, TCP connection forwarding enables all of the appliances to share connection 
information (for each new connection) and the in-line SG appliance routes the request 
back to the originating appliance, thus lightening the load on the inline appliance. 




In the above network topography, SG appliance SG 1 is deployed inline to receive all 
traffic (by way of a switch) originating from the clients to the servers and servers to the 
clients and serves as a load balancer to the other four SG appliances. Appliances 2 through 
5 also have independent connectivity to the clients and the servers. When all appliances 
belong to the same peering cluster and have connection forwarding enabled, appliance SG 
1 knows which of the other appliances made a specific connection and routes the response 
to that appliance. 

In this deployment, a TCP acknowledgement is sent and retransmitted, if required, to 
ensure the information gets there, but each new connection message is not explicitly 
acknowledged. However, if the SG appliance receives packets for a connection that is 
unrecognized, the appliance retains those packets for a short time before deciding 
whether to forward or drop them, which allows time for a new connection message from a 
peer to arrive. 

While adding more peers to a cluster increases the connection synchronization traffic, the 
added processing power all but negates that increase. You can have multiple peer clusters, 
and if you are cognoscente of traffic patterns to and from each cluster, you can create an 
effective cluster strategy. The only limitation is that an SG appliance can only be a peer in 
one cluster. 

The Blue Coat load balancing solution is discussed in greater detail in earlier sections of 
this chapter. 

About ADN Transparent Tunnel Load Balancing 

TCP connection forwarding is a critical component of the Blue Coat ADN transparent 
tunnel load balancing deployment. Achieving efficient load balancing is difficult when 
ADN transparent tunneling is employed and an external load balancer is distributing 
requests to multiple SG appliances. 
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A user-noticeable performance degradation occurs if the router, switch, or load balancer 
sends traffic to an SG appliance that has not been servicing a particular client long enough 
to build up substantial byte caching dictionary, thus the compression ratio is low. When 
the SG appliances connected to the routing device belong to the same peer cluster and 
connection forwarding is enabled, the ADN managers on each appliance know which of 
their peers has the best byte caching dictionary with the client and forwards the request. 
This is illustrated in the following diagram. 




Client 3 



Flow: 

1 : Client 3 in a branch office makes another in a series of requests to a server at a corporate location. 

2. The load balancer forwards a series of requests to SG appliance SG 2. 

3. SG 2 has been servicing Client 3 and the ADN manager has built up a substantial compression ratio 
with the ADN manager with SG 4 at the corporate location. 

4. SG 4 at the corporate location contacts the server and sends the response that it receives from the 
server. 

5. The load balancer sends the next request to SG 3. 

6. SG 3 knows SG 2 has a better compression ratio with this client, and the ADN manager towards the 
request over to SG 2. 



Figure 7-4. ADN Transparent Tunnel load balancing with Connection Forwarding enabled 



Load balancing is based on the IP address of the remote ADN peer. This assures that all 
the traffic from a particular ADN peer to the local ADN cluster always goes to a specific 
local SG appliance, thus eliminating the inefficiency of keeping dictionaries for that 
remote peer on more than one local SG appliance. 

The Blue Coat ADN solution is discussed in greater detail in Chapter 2: "Configuring an 
Application Delivery Network" on page 11. 
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TCP Configuration Forwarding Deployment Notes 

When configuring your network for TCP connection forwarding, consider the following: 

□ Peers can be added to clusters at any time without affecting the performance of the 
other peers. An SG appliance that joins a peer cluster immediately contacts every other 
peer in the cluster. Likewise, a peer can leave a cluster at anytime. This might be a 
manual drop or a forced drop because of a hardware or software failure. If this 
happens, the other peers in the cluster continue to process connection forwarding 
requests. 

□ Connections between peers are not encrypted and not authenticated. If you do not 
assign the correct local IP address on an SG appliance with multiple IP addresses, 
traffic sent peer to peer might be routed through the Internet, not the intranet, 
exposing your company-sensitive data. 

□ The peering port — the connection between SG appliance connection forwarding 
peers — cannot be configured with bypass services. This means an SG appliance cannot 
be deployed in transparent mode between two SG appliances that are peers. 

□ SG does not enforce a maximum number of appliances a peer cluster supports, but 
currently the deployment is designed to function with up to 20 SG appliances. 

□ Because TCP connection forwarding must function across different network segments, 
employing multicasting, even among SG appliance peers on the same network, is not 
supported. 

□ There might be a slight overall performance impact from enabling TCP connection 
forwarding, especially in deployments where traffic is largely already being routed to 
the correct SG appliance. If a substantial amount of traffic requires forwarding, the 
performance hit is equitable to processing the same amount of bridging traffic. 

Configuring TCP Connection Forwarding 

As described in the previous concept sections, enabling TCP connection forwarding 
provides one component to a larger deployment solution. After you have deployed Blue 
Coat appliances into the network topography that best fits your enterprise requirements, 
enable TCP connection forwarding on each Blue Coat appliance that is to belong to the 
peering cluster, and add the IP address of the other peers. The peer lists on all of the 
cluster members must be the same, and an SG appliance cannot have a different local peer 
IP address than what is listed in another peers list. A peer list can contain only one local IP 
address. 

To enable TCP Connection Forwarding: 

1. Select Configuration > Network > Advanced > Connection Forwarding. 
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WCCP | VIPs | Failover Connection Forwarding 



-o 0 Enable Connection Forwarding 
Local IP: 10.9.59.246 v 

Port: 3030 





2. From the Local IP drop-down list, select the IP address that is routing traffic to this SG 
appliance. 



Specify the port number (the default is 3030 ) that the SG appliance uses to 
communicate with all peers, which includes listening and sending out connection 
forwarding cluster control messages to all peers in the group. All peers in the group 
must use the same port number (when connection forwarding is enabled, you cannot 
change the port number). 



3. Add the cluster peers: 

a. Click Add. 

b. In the Peer IPs field, enter the IP addresses of the other peers in the cluster 
that this SG appliance is to communicate connection requests with.; click OK. 



4. Select Enable Connection Forwarding. 

5. Click Apply. 



This SG appliance joins the peer cluster and immediately begins communicating with its 
peers. 



Copying Peers to Another SG Appliance in the Cluster 

If you have a larger cluster that contains several peer IP addresses, select all of the IP 
addresses in the Connection Forwarding Peer IPs list and click Copy To Clipboard; this 
action includes the local IP address of the peer you are copying from, and it will be 
correctly added as a remote peer IP address on the next appliance. When you configure 
connection forwarding on the next appliance, click Paste From Clipboard to paste the list of 
peers, and click Apply. Whichever peer IP address is the new appliance's local IP address 
is pulled out of the list and used as the local IP address on the new appliance. If a local IP 
address is not found or if more than one local IP address is found, the paste fails with an 
error. 
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Removing a Peer 

A network change or other event might require you to remove a peer from the cluster. 
Highlight a peer IP address and click Remove. The peer connection is terminated and all 
connections associated with the peer are removed from the local system. 



Note: A CLI command is available that allows you to disable a peer, which terminates 
the communication with other peers, but does not remove the peer from the cluster. See 
the next section. 



Related CLI Syntax to Configure TCP Connection Forwarding 

□ To enter configuration mode: 

SGOS# (config) connection- forwarding 

□ The following subcommands are available: 

SGOS# (config connection forwarding) add ip_address 
SGOS# (config connection forwarding) port number 
SGOS# (config connection forwarding) [enable | disable] 

SGOS# (config connection forwarding) [clear | remove ip_address ] 
SGOS# (config connection forwarding) [view | exit] 

□ The following configuration and statistics commands are available: 

SGOS# show connection- forwarding configuration 
SGOS# show connection- forwarding statistics 
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This chapter discusses health checks for services and hosts and describes how to 
configure the SG appliance. 



About General Health Checks 

The SG appliance can perform health checks on a forwarding host or external server 
that is providing a service. The supported server types are HTTP, HTTPS, ICAP, 
Websense (off-box), and SOCKS gateways, Layer-3, and Layer 4 forwarding hosts. 

When a health check reports a target as sick, this allows a much quicker failure for a 
connection attempt than might otherwise occur. The health check also drives the fail- 
over mechanisms in the forwarding groups, external service groups, and forwarding 
policy sequences. 

Based on the health check type, the SG appliance periodically verifies the health status, 
and thus the availability, of the host. The time interval between checks is configurable. 
If the health check is successful, the appliance considers the host available. If the initial 
health check is not successful for a host, the SG appliance retries, using the number of 
consecutive successes or failures meet the configured thresholds to trigger a change of 
health check state. 

If the health check is not successful for every server in a domain, stale content might be 
served, depending on the SG configuration. 

The following table describes the types of health checks. 



Table 8-1 . Health Check Types 



Health Check Type 


Description 


HTTP 


Use this type to confirm that the host can fulfill a content 
request over HTTP by the SG appliance. The appliance 
accepts only a 200 OK as a healthy response. 


Criterion for success 


The SG appliance fetches the object. 


Criterion for failure 


The SG appliance cannot fetch the object. 


HTTPS 


Use this type to confirm that the host can fulfill a content 
request over HTTPS by the SG appliance. The appliance 
accepts only a 200 OK as a healthy response. 


Criterion for success 


The SG appliance fetches the object. 


Criterion for failure 


The SG appliance cannot fetch the object. 


Layer-3 health check 


Use this type to confirm the basic connection between the SG 
appliance and the origin server. The server must recognize 
ICMP echoing. The SG appliance sends a ping (three Internet 
Control Message Protocol [ICMP] echo requests) to the host. 


Criterion for success 


The SG appliance receives at least one ICMP echo reply. 


Criterion for failure 


The SG appliance does not receive a single ICMP echo reply. 
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Table 8-1. Health Check Types (Continued) 



Health Check Type 


Description 


Layer-4 health check 


Use this type to confirm that the SG appliance can connect to 
the host HTTP and FTP ports. The SG appliance attempts to 
establish a TCP connection to an HTTP port or FTP port on 
the host. 


Criterion for success 


The SG appliance establishes the connection to the defined 
port (of any type), then closes it. For global forwarding 
checks, the first defined port in the forwarding host port list 
is used for the attempt (except for SOCKS gateways, in 
which the SOCKS port is used). 


Criterion for failure 


The SG appliance cannot establish the connection. 


ICAP health check and 
Websense 4 off-box 


Requests are not sent to sick services. If a health check 
determines the service is healthy, requests resume. 



Configuring Service-Specific Health Checks 

This section describes how to create a health check service for a specific host (for example, 
an ICAP server). A failed health check results in administrator notification; however, no 
action is taken to control any traffic. 

To configure health checks: 

Part 1: General Tasks 

This part of the procedures is the same for all health check types. 

1. Select Configuration > Health Checks > General. 

2. Click New. 

3. In the Add Health Check dialog, specify a name for the health check service; click OK. 

4. In the Health Check list, select the newly created service and click Edit. 
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5. Configure options: 

a. Select the health check type (HTTP, HTTPS, ICAP, Layer-3, Layer-4, or Websense 
off-box). 

b. Specify the healthy interval, in seconds, between health checks to the server. 

The default is 1 0. 

c. Specify the sick interval, in seconds, between health checks to the server that 
has been determined to be sick, or out of service. The default is 1 0. 

d. Specify the failure trigger for the number of failed connections to the server 
before a health check is triggered. If the external service experiences a 
connection failure during a connection attempt, the service reports the event 
to the health checks system. Valid values are 0-65535, where 0 disables the 
trigger. The default is 0. 

e. Specify the healthy threshold for the number of successful health checks 
before an entry is considered healthy. Valid values are 1-65535. The default is 

1 . 

f. Specify the sick threshold, or the number of failed health checks before an 
entry is considered sick. Valid values are 1-65535. The default is 1 . 

6. Optional: Select the Notify via email checkbox to send notification mail when the 

health of a service changes. Recipients are specified in Management > Event Logging > 

Mail. 
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Part 2: Health Check Type Specific Tasks 

This part of the procedure configures the health check based upon the type selected in the 

ICAP Options field. 




1. Upon selecting the health check type, the Options section of the dialog changes to 

display the appropriate configuration fields. Enter the required information: 

• HTTP and HTTPS: Enter the URL of the server to be checked. 

• ICAP: Select the ICAP service. The ICAP service must already be configured on 
the SG appliance (refer to Volume 8: Managing Content). 

• Layer-3 and Layer-4: Enter the host name; for Layer-4, also enter the port number. 

• Websense off-box: Select the Websense service. The Websense service must 
already be configured on the SG appliance (refer to Volume 8: Managing Content: 
Section G: "Configuring Websense Off-box Content Filtering" on page 44). Enter 
the URL to be test-categorized, or click Use default. 

2. Click OK to close the Edit Health Check dialog; 

3. Select Apply to commit the changes to the SG appliance. 

Issuing an Instant Health Check 

You can manually issue a health check request. 

To issue a health check: 

1. Select Health Checks>General. 

2. Select a health check name. 

3. Click Edit. 

4. Click Health Check. 



Viewing Health Check Statistics 

You can display a page that displays all user-created health check statistics, organized by 
health check service. 

To display health check statistics: 

1. Select Configuration > Health Checks > General. 
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2. Click Statistics. 

The Health Check Statistics page appears. For example: 
ICAPl 

State: Functioning properly 

Last success: Wed, 23 Nov 2005 20:56:15 GMT 
Number of successes: 86 
Consec. successes: 86 

Last failure: Wed, 23 Nov 2005 20:41:14 GMT 

Number of failures: 1 

Consec. failures: 0 

External failures: 0 

Response time: 586 ms 



About Global Forwarding and SOCKS Gateway Health Checks 

This section describes health checks that can be configured on the SG appliance that apply 
to all forwarding hosts and SOCKS gateway hosts. 

When the SG appliance performs a health check on one or more hosts, it determines 
whether the host returns a response and is available to fill a content request. A positive 
health check indicates that there is an end-to-end connection and that the host is healthy 
and is able to return a response. 

With multiple forwarding hosts, health checks are vital to SG efficiency. When hosts 
respond positively to health checks, the ProxySG forwards requests to those hosts and not 
to unavailable hosts, which provides quicker content fill requests. With a single 
forwarding host, health checking is also important to determine whether the host is 
available. 



Note: When a forwarding host or SOCKS gateway is created, it is automatically 
registered for health checks. Similarly, when a forwarding host or SOCKS gateway is 
deleted, it is removed from the health check registry. 



Configuring Global Health Checks 

This section describes how to configure the SGOS software to perform global health 
checks. 

To configure global forwarding or SOCKS gateway health checks: 

1. Select Configuration > Health Checks > Forwarding or SOCKS Gateway. 

Forwarding Health Checks 




2a 

2b 



2c 

2d 
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2. Configure the options: 

a. Select the health check type: 

• Forwarding — HTTP, HTTPS, Layer-3, or Layer-4. 

• SOCKS Gateway — Layer-3 or Layer-4. 

b. (HTTP/ HTTPS option only) Object name — Enter a relative URL (path) to test a 
server or enter a full URL, (including scheme and hostname) to test a proxy. 

A full URL scheme must match the HTTP or HTTPS test to be accepted. If the 
test is performed on a mix of servers and proxies, the health check attempts to 
make up a full URL out of the path and make a path out of the full URL, as 
required. Lor a proxy, enter the full URL of the upstream target. If you have a 
mixture of servers and proxies, the full URL to work for them and the path of 
the URL to still be reasonable for the servers. 

c. Specify the interval, in seconds, between health checks. The default is 60. 

d. Specify the failure count, which specifies the number of sequential failures 
before the host is considered down. The default is 5. 

3. Select Apply to commit the changes to the SG appliance. 

Pausing or Resuming Global Health Checking 

You can temporarily halt global health checks and resume when ready. This is helpful if 
the SG appliance must be temporarily taken out of service. 



Note: If the health check is paused, the state remains paused until the resume option is 
invoked. The paused state remains even after a reboot. 



To pause or resume health checking: 

1. Select Configuration > Health Checks > Forwarding or SOCKS Gateway. 

2. Click Pause. 

3. To resume health checks, click Resume. 

Related CLI Syntax to Manage Health Checks 

□ To enter configuration mode: 

SGOS# (config) health-check 
SGOS# (config health-check) 

□ The following subcommands are available: 

SGOS# (config health-check) forwarding type {http | https | layer-3 
layer-4 } 

SGOS# (config health- check) forwarding interval seconds 
SGOS# (config health-check) forwarding failcount count 

SGOS# (config health-check) socks-gateways type {layer-3 | layer-4} 

SGOS# (config health-check) socks-gateways interval seconds 

SGOS# (config) health-check) socks-gateways failcount count 

SGOS# (config) health-check) {forwarding | socks-gateway} {pause | 

resume} 

SGOS# (config health-check) create name 
SGOS# (config health-check) edit name 
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SGOS# (config health-check name ) type {layer-3 | layer-4 | http | https 
| icap | websense-of fbox} 

SGOS# (config health-check name) type parameter 
SGOS# (config) health-check name) perf orm-health-check 
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ICP is a communication protocol for caches. It allows a cache (not necessarily a SG 
appliance) to query other caches for an object, without actually requesting the object. By 
using ICP, the cache can determine if the object is available from a neighboring cache, 
and which cache provides the fastest response. 



Note: The SG appliance (assuming ICP is configured) does ICP queries only if no 
forwarding host or SOCKS gateway is identified as an upstream target. If ICP is used by 
the appliance, it prompts other cache devices for the item, and upon a positive response 
re-directs the upstream request to that cache device instead of the content origin server. 



Only use ICP if you have ICP hosts available or to have the SG appliance support 
requests from other ICP hosts. 

By default, the ICP protocol requires the requesting host to wait up to two seconds for 
all ICP hosts to respond to the request for an object (the time is configurable). 

If the ICP service is configured and running, the service is used if no forwarding or 
SOCKS gateway target was specified. In other words, the policy rule icp (yes) is the 
default, assuming that the ICP service is available. You can disable ICP with the policy 
rule icp (no) to control ICP queries for requests. 

Configuring ICP 

An ICP hierarchy is comprised of a group of caches, with defined parent and sibling 
relationships. A cache parent is one that can return the object if it is in the cache, or 
request the object from the source on behalf of the requester if the object is not in the 
cache. A cache sibling is a device that can only return the object if it is in the cache. One 
cache acting as a parent can also act as a sibling to other cache devices. 

□ When an object is not cached, the cache device sends an ICP query to its neighbors 
(parents and siblings) to see if any of its peers holds the object. 

□ Each neighbor that holds the requested object returns an ICP_HIT reply. 

□ Each neighbor that does not hold the object returns an ICP_MISS reply. 

Based on the responses, the cache can determine where to request the object: from one 
of its neighbors or from the source. If an icp hit reply is received, the request is sent to 
the host that returned the first reply. If no icp hit reply is received, the request is 
forwarded to the first parent that replied. If no parents respond or are configured, the 
request is made directly to the source. 

Using ICP Configuration Directives to Create an Installable List 

To configure ICP you must create an installable list and load it on the SG appliance. The 
ICP protocol contains a number of directives, commands used to create a list that can be 
installed on the SG appliance. 

For information on installing the file itself, see "Creating an ICP Installable List" on 
page 81 . 

The ICP configuration includes directives that: 
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□ Name the ICP hosts 

□ Restrict ICP access to only these hosts 
Available directives are listed in Table 9-1 . 



Table 9-1 . ICP Directives 



Directive 


Meaning 


Where used 


icp_host 


The icp host directive describes cache peers in the 
hierarchy. There should be one entry for each SG 
appliance you want to use. 


Names the ICP hosts. See 
"Naming the IP Hosts" on 
page 129. 


icp access domain 


The icp access domain directive is used to control 
which ICP queries are accepted. The 
icp_access_domain directive requires a reverse DNS 
lookup of each ICP query to validate the IP address. 


Restricts access. See 
"Restricting Access" on 
page 129. 


icp_access_ip 


The icp access ip directive works like the 
icp access domain command, except that you can 
specify an IP address and subnet mask rather than a 
domain. 


Restricts access. 

See "Restricting Access" on 
page 129. 


icp_port 


The icp port directive sets the port the SG appliance 
uses to listen for ICP requests. The default port is 3130. 
If you set the port to 0, ICP is disabled. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 131. 


neighbor timeout 


The neighbor timeout directive sets the number of 
seconds the SG appliance waits for ICP replies. When 
the cache device sends an ICP request, it waits for all 
hosts to reply or for the neighbor timeout to expire. 
The default timeout is two seconds. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 131. 


icp failcount 


The icp failcount directive sets the number of 
consecutive failures the cache device can receive before 
considering the ICP host as failed. By default, the ICP 
failure count is set to 20. Each time a request fails, the 
failure count is incremented. When a request succeeds, 
the failure count is reset to zero. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 131. 


http failcount 


The http failcount directive sets the number of 
consecutive failures the cache device can receive before 
considering the HTTP host as failed. By default, the 
HTTP failure count is set to five. The failure count 
increments each time a request fails. When a request 
succeeds, the failure count is reset to zero. When an 
HTTP host fails, the cache device waits five minutes 
before attempting to use it again as a forwarding target. 
If the next request fails, the cache device continues to 
wait five minutes between attempts until the cache 
becomes available. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 131. 


host_fail_notify 


The host fail notify directive tells the cache 
device to send event notification e-mail when a connect 
fails persistently. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 131. 


host recover 
notify 


The host recover notify directive tells the cache 
device to send event notification e-mail when a failed 
host recovers. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 131. 
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Naming the IP Hosts 

The icp host directive describes peers in the hierarchy. One entry is required for each SG 
appliance you want to use. 

icp_host hostname peertype HTTPport ICPport [default | backup | 
feeder] 



Table 9-2. ICP„host Directive 



Command 


Suboptions 


Description 


hostname 




The host name of the SG appliance. 


peertype 


{parent | 
sibling} 


Relationship of the SG appliance to the cache device you are configuring. 


HTTPport 




TCP port where the SG appliance accepts HTTP requests. The common HTTP 
port is 80 or 8080. 


ICPport 




UDP port where the SG appliance accepts ICP requests. The common ICP port 
is 3130. 


default 




If specified, designates a SG host parent to be the default ICP parent. If no ICP 
reply is received, all requests are forwarded to the default parent. 


backup 




If specified, designates the cache device host parent to be the backup default 
ICP parent. If the default parent is not available, the cache device uses the 
backup default parent. 


feeder 




If specified, designates the SG host sibling as a feeder-type host, using ICP 
request loops to populate the appliance. 



The following are sample icp host directives that can be entered into the ICP 
configuration: 



; Define 
icp_host 
icp_host 
icp_host 
icp_host 
icp_host 



ICP parent and sibling hosts. 



cml . bluecoat . com 
cm2 . bluecoat . com 
cm3 . bluecoat . com 
cm4 . bluecoat . com 
cm5 . bluecoat . com 



parent 8080 3130 default 
sibling 8080 3130 
sibling 8080 3130 
sibling 8080 3130 
parent 8080 3130 



Restricting Access 

You can restrict access to SG appliances acting as caches by other ICP hosts using the 
icp_access_domain and icp_access_ip directives. By default, when ICP is configured, 
all ICP hosts are allowed access. You should deny access to all domains other than the ICP 
hosts you want to use. 

icp_access_domain Directive 

The icp_access_domain directive defines which hosts can request objects from the Web 
cache using ICP. The default action is to allow all requests. When you use 
icp_access_domain, each ICP query requires a reverse DNS lookup to validate the IP 
address. Depending on the number of ICP requests, these lookups can consume SG 
appliance resources. 

icp_access_domain {allow | deny} domain 
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Table 9-3. ICP_Access_Domain Directive 



Directive Option 


Description 


allow | deny 


Allows or denies ICP queries from neighbors that match the domain 
specification. 


domain 


The domain to match. All ICP queries from neighbors that match the 
specified domain are handled by the host. The special domain of all 
defines the default action when there is no domain match. 



The following are sample icp_access_domain directives to be entered into the 
ICP configuration: 



; allow ICP access to this Blue Coat Systems ProxySG Appliance from 
the 

; bluecoat . com domain 

icp_access_domain allow bluecoat.com 
icp_access_domain deny all 

; the deny all option should always be specified to deny all other 
; domains 

icp_access_ip Directive 

The icp_access_ip directive works like the icp_access_domain command, except that 
you can specify an IP address and subnet mask rather than a domain. The following 
describes the parameters for the icp_access_ip command: 

icp_access_ip {allow | deny} subnet mask 



Table 9-4. ICAP_Access_IP Directive 



Directive Option 


Description 


allow | deny 


Allow or deny ICP queries from neighbors that match the address 
specification. 


address/subnet mask 


The address and subnet mask to match. All ICP queries that match 
the specified address are handled by the ICP host. The special 
address of 0 . 0 . 0 . 0 defines the default action when there is no 
address match. 



The following are sample icp access ip directives to be entered into the ICP 
configuration: 

; allow ICP access to this Blue Coat Systems ProxySG Appliance from 
the local subnet 

icp_access_ip allow 192.168.10.0/255.255.255.0 
icp_access_ip deny 10.25.36.47 

; the deny all option should always be specified to deny all other 
domains 
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Connecting to Other ICP Hosts 

In addition to the ICP directives described in the sections above, you can specify the 
following directives in the ICP configuration: 

icp_port 0 
neighbor_timeout 2 
icp_f ailcount 20 
http_f ailcount 5 
host_f ail_notify on 
host_recover_notify on 



Table 9-5. Connecting to Other ICP Hosts 



Directive 


Description 


icp_port 


The default port is 3130. If you set the port to 0, ICP is disabled. 


neighbor timeout 


When the cache device sends an ICP request, it waits for all hosts to 
reply or for the neighbor timeout to expire. The default timeout is 
two seconds. 


http_f ail count 


By default, the HTTP failure count is set to five. The failure count 
increments each time a request fails. When a request succeeds, the 
failure count resets to zero. When an HTTP host fails, the cache device 
waits five minutes before attempting to use it again as a forwarding 
target. 


icp_failc ount 


By default, the ICP failure count is set to 20. Each time a request fails, 
the failure count is incremented. When a request succeeds, the failure 
count is reset to zero. 


host_fail_notify 


on tells the cache to send event notification e-mail when a connect fails 
persistently; off disables this setting. 


host recover 
notify 


on tells the cache to send event notification e-mail when a failed host 
recovers; of f disables this setting. 



Creating an ICP Installable List 

You can create the ICP installable list using one of the following methods: 

□ Text Editor, which allows you to enter directives (or copy and paste the contents of an 
already -created file) directly onto the SG appliance. 

□ Local file, installed on your system; the SG appliance can browse to the file and install 
it. 

□ A remote URL, where you place an already-created file on an FTP or HTTP server to be 
downloaded to the SG appliance. 

□ The CLI inline command. 

When the ICP installable list is created and installed, it overwrites any ICP settings on the 

SG appliance. 

To create an ICP installable list: 

1. Select Configuration > Forwarding > ICP. 

From the drop-down list, select the method you want to use to install the ICP 
configuration; then click Install. 



2 . 



131 



Volume 6: Advanced Networking 



• Remote URL: 

Enter the fully-qualified URL, including the filename, where the configuration is 
located. To view the file before installing it, click View. Click Install. Examine the 
installation status that displays; click OK. 

• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file on the 
local system. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, click Close. 

• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the installation is 
complete, a results window opens. View the results, close the window, click Close. 

3. Select Apply to commit the changes to the SG appliance. 



Note: You can create ICP settings using the CLI inline commands. 

For more information on using inline commands, refer to Volume 12: Command Line 
Reference. 



Enabling ICP 

Before ICP can be used in the SG environment: 

□ ICP must be running 

□ At least one forwarding host must be configured 

ICP can be enabled or disabled through the policy rule icp . The default is icp (yes ) . You 
can disable ICP with the policy rule icp (no) to control ICP queries for requests. 
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The Routing Information Protocol (RIP) is designed to select the fastest route to a 
destination. RIP support is built into the SG appliance, and is configured by created and 
installing an RIP configuration text file onto the device. 

The Blue Coat RIP implementation also supports advertising default gateways. Default 
routes added by RIP are treated the same as the static default routes; that is, the default 
route load balancing schemes apply to the default routes from RIP as well. 

This chapter discusses: 

□ "Installing RIP Configuration Files" on page 133 

□ "Configuring Advertising Default Routes" on page 134 
a "RIP Commands" on page 135 

□ "RIP Parameters" on page 136 

□ "SG-Specific RIP Parameters" on page 137 

□ "Using Passwords with RIP" on page 137 

Installing RIP Configuration Files 

No RIP configuration file is shipped with the appliance. For commands that can be 
entered into the RIP configuration file, see "RIP Commands" on page 135. 

After creating an RIP configuration file, install it using one of the following methods: 

□ Using the Text Editor, which allows you to enter settings (or copy and paste the 
contents of an already-created file) directly onto the appliance. 

□ Creating a local file on your local system; the SG appliance can browse to the file and 
install it. 

□ Using a remote URL, where you place an already-created file on an FTP or HTTP 
server to be downloaded to the SG appliance. 

□ Using the CLI inline rip-settings command, which allows you to paste the RIP 
settings into the CLI. 

□ Using the CLI rip commands, which require that you place an already-created file 
on an FTP or HTTP server and enter the URL into the CLI. You can also enable or 
disable RIP with these commands. 

To install an RIP configuration file: 



Note: When entering RIP settings that affect current settings (for example, when 
switching from ripvl to ripv2), disable RIP before you change the settings; re-enable 
RIP when you have finished. 



1. Select Configuration > Network > Routing > RIP. 

2. To display the current RIP settings, routes, or source, click one or all of the View RIP 
buttons. 
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3. In the Install RIP Setting from the drop-down list, select the method used to install the 
routing table; click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the routing table is 
located. To view the file before installing it, click View. Click Install. To view the 
installation results, click Results; close the window when you are finished. Click 

OK. 

• Local File: 

Click Browse to display the Local File Browse window. Browse for the file on the 
local system. Open it and click Install. When the installation is complete, a results 
window opens. View the results and close the window. 

• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the installation is 
complete, a results window opens. View the results, close the window, and click 

OK. 

4. Select Apply to commit the changes to the SG appliance. 

5. Select Enable RIP. 

6. Click Apply. 



Related CLI Syntax to Configure RIP 

SGOS# (config) rip {disable | 



enable } 



To enter a path to a remote URL where you have placed an already-created RIP 
configuration file, enter the following commands at the (config) command prompt: 

SGOS# (config) rip path url 
SGOS# (config) load rip-settings 

To paste an RIP configuration directly into the CLI, enter the following command at 
the (config) command prompt: 

SGOS# (config) inline rip-settings end-of-file_marker 



Configuring Advertising Default Routes 

Default routes advertisements are treated the same as the static default routes; that is, the 
default route load balancing schemes also apply to the default routes from RIP. 

By default, RIP ignores the default routes advertisement. You can change the default from 
disable to enable and set the preference group and weight through the CLI only. 

To enable and configure advertising default gateway routes: 

1. At the (config) command prompt: 

SGOS# (config) rip default-route enable 

SGOS# (config) rip default-route group group_number 
SGOS# (config) rip default-route weight weight_number 

Where group_number defaults to 1, and weight_number defaults to 10 0, the same 
as the static default route set by the ip-default-gateway command. 
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2. (Optional) To view the default advertising routes, enter: 

SGOS# (config) show rip default-route 

RIP default route settings: 

Enabled: Yes 

Preference group: 3 

Weight: 30 

RIP Commands 

You can place any of the commands below into a Routing Information Protocol (RIP) 
configuration text file. You cannot edit a RIP file through the command line, but you can 
overwrite a RIP file using the inline rip-settings command. 

Once the file is complete, place it on an HTTP or FTP server accessible to the SG appliance 
and download it. 



net 



net Nname[/mask ] gateway Gname metric Value {passive | active | 
external } 



Table 1 0-1 . net Commands 



Parameters 


Description 


Nname 


Name of the destination network. It can be a symbolic network 
name, or an Internet address specified in dot notation. 


/ mask 


Optional number between 1 and 32 indicating the netmask 
associated with Nname. 


Gname 


Name or address of the gateway to which RIP responses should be 
forwarded. 


Value 


The hop count to the destination host or network. A net Nname/ 32 
specification is equivalent to the host Hname command. 


passive | active | 
external 


Specifies whether the gateway is treated as passive or active, or 
whether the gateway is external to the scope of the RIP protocol. 



host 



host Hnarae gateway Gname metric Value {passive | active | external} 



Table 10-2. host Commands 



Parameters 


Description 


Hname 


Name of the destination network. It can be a symbolic network 
name, or an Internet address specified in dot notation. 


Gname 


Name or address of the gateway to which RIP responses should be 
forwarded. It can be a symbolic network name, or an Internet 
address specified in dot notation. 


Value 


The hop count to the destination host or network. A net Nname/ 32 
specification is equivalent to the host Hname command. 


passive | active | 
external 


Specifies whether the gateway is treated as passive or active, or 
whether the gateway is external to the scope of the RIP protocol. 



135 



Volume 6: Advanced Networking 



RIP Parameters 

Lines that do not start with net or host commands must consist of one or more of the 
following parameter settings, separated by commas or blank spaces: 



Table 10-3. RIP Parameters 



Parameters 


Description 


if = [0 | 1 | 2 | 3] 


Specifies that the other parameters on the line apply to the interface numbered 0,1,2, 
or 3 in SGOS terms. 


passwd=XXX 


Specifies an RIPv2 password included on all RlPv2 responses sent and checked on all 
RIPv2 responses received. The password must not contain any blanks, tab characters, 
commas or '#' characters. 


no_ag 


Turns off aggregation of subnets in RIPvl and RIPv2 responses. 


no_super_ag 


Turns off aggregation of networks into supernets in RIPv2 responses. 


passive 


Marks the interface to not be advertised in updates sent through other interfaces, and 
turns off all RIP and router discovery through the interface. 


no rip 


Disables all RIP processing on the specified interface. 


no ripvl in 


Causes RIPvl received responses to be ignored. 


no ripv2 in 


Causes RIPv2 received responses to be ignored. 


ripv2_out 


Turns off RIPvl output and causes RIPv2 advertisements to be multicast when 
possible. 


ripv2 


Is equivalent to no ripvl in and no ripvl out. This parameter is set by default. 


no_rdisc 


Disables the Internet Router Discovery Protocol. This parameter is set by default. 


no solicit 


Disables the transmission of Router Discovery Solicitations. 


send_solicit 


Specifies that Router Discovery solicitations should be sent, even on point-to-point 
links, which by default only listen to Router Discovery messages. 


no rdisc adv 


Disables the transmission of Router Discovery Advertisements. 


rdisc adv 


Specifies that Router Discovery Advertisements should be sent, even on point-to- 
point links, which by default only listen to Router Discovery messages. 


bcast_rdisc 


Specifies that Router Discovery packets should be broadcast instead of multicast. 


rdisc pref=N 


Sets the preference in Router Discovery Advertisements to the integer N. 


rdisc interval=N 


Sets the nominal interval with which Router Discovery Advertisements are 
transmitted to N seconds and their lifetime to 3*N. 


trust gateways rname 


Causes RIP packets from that router and other routers named in other trust_gateway 
keywords to be accept, and packets from other routers to be ignored. 


redirect ok 


Causes RIP to allow ICMP Redirect messages when the system is acting as a router 
and forwarding packets. Otherwise, ICMP Redirect messages are overridden. 



136 



Chapter 10: Using RIP 



SG-Specific RIP Parameters 

The following RIP parameters are unique to SG configurations: 



Table 10-4. SG-Specific RIP Parameters 



Parameters 


Description 


supply routing info 


- s option: 


-or- 


Supplying this option forces routers to supply routing 
information whether it is acting as an Internetwork router or not. 


advertise routes 


This is the default if multiple network interfaces are present or if a 
point-to-point link is in use. 

- g option: 

This flag is used on Internetwork routers to offer a route to the 
'default' destination. This is typically used on a gateway to the 
Internet, or on a gateway that uses another routing protocol 
whose routes are not reported to other local routers. 

- h option: 

Suppress extra host routes advertise host route 
-m option: 

Advertise host route on multi-homed hosts 
-A option: 

Ignore_authentication / / 


no_supply_ 


- q option: 


routing info 


opposite of -s. 


no rip out 


Disables the transmission of all RIP packets. This setting is the 
default. 


no ripvl out 


Disables the transmission of RIPvl packets. 


no ripv2 out 


Disables the transmission of RIPv2 packets. 


rip out 


Enables the transmission of RIPvl packets. 


ripvl out 


Enables the transmission of RIPvl packets. 


rdisc 


Enables the transmission of Router Discovery Advertisements. 


ripvl 


Causes RlPvl packets to be sent. 


ripvl in 


Causes RIPvl received responses to be handled. 



Using Passwords with RIP 

The first password specified for an interface is used for output. All passwords pertaining 
to an interface are accepted on input. For example, with the following settings: 

if=0 passwd=aaa 
if=l passwd=bbb 
passwd=ccc 

Interface 0 accepts passwords aaa and ccc, and transmits using password aaa. Interface 1 
accepts passwords bbb and ccc, and transmits using password bbb. The other interfaces 
accept and transmit the password ccc . 
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Monitor 



You can configure the SGOS software to monitor RADIUS accounting messages and to 
maintain a session table based on the information in these messages. The session table 
can then be used for logging or authentication. 

You can also, optionally, configure multiple appliances to act as a session monitor 
cluster. The session table is then replicated to all members of the cluster. 

Once configured and enabled, the session monitor maintains a session table that 
records which sessions are currently active and the user identity for each session. 



Configuring the Session Monitor 

Three steps are required to configure the session monitor: 

□ Configure the RADIUS accounting protocol parameters for the session monitor. 

□ (Optional) Configure the session monitor cluster. 

□ Configure the session monitor parameters. 



Configuring the RADIUS Accounting Protocol Parameters 

The configuration commands to create the RADIUS accounting protocol parameters 
can only be done through the CLI. If you are using session-monitor clustering, the 
commands must be invoked on each system in an already-existing failover group. (For 
information on configuring a failover group, see Chapter 6: "Configuring Failover'on 
page 87.) 



To configure the RADIUS accounting protocol parameters: 

□ To enter configuration mode: 

SGOS# (config) session-monitor 



□ 



The following subcommands are available: 

SGOS# (config session-monitor) radius 

SGOS# (config session-monitor) radius 
disable } 

SGOS# (config session-monitor) radius 
encrypt ed_secret 



acct- listen-port port_number 
authentication {enable | 

encrypted- shared- secret 



SGOS# (config 
SGOS# (config 
SGOS# (config 



session- monitor) 
session-monitor) 
session- monitor) 



radius no encrypted- shared- secret 
radius response {enable | disable} 
radius shared- secret plaintext_secret 
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Table 11-1. Session Monitor Accounting Command Descriptions 



Command 


Option 


Description 


radius acct-listen-port 


port number 


The port number where the SG appliance listens for 
accounting messages 


radius authentication 


enable | disable 


Enable or disable (the default) the authentication of 
RADIUS messages using the shared secret. Note 
that the shared secret must be configured before 
authentication is enabled. 


radius encrypted-shared- 
secret 


encrypted shared 
secret 


Specify the shared secret (in encrypted form) used 
for RADIUS protocol authentication. The secret is 
decrypted using the configuration-passwords-key. 


radius no shared- secret 




Clears the shared secret used for RADIUS protocol 
authentication. 


radius response 


enable | disable 


Enable (the default) or disable generation of 
RADIUS responses. 


radius shared- secret 


plaint ext_secret 


Specify the shared secret used for RAIDUS protocol 
in plaintext. 



Configuring a Session Monitor Cluster 

Configuring a session monitor cluster is optional. When a session monitor cluster is 
enabled, the session table is replicated to all members of the cluster. The cluster members 
are the SG appliances that are configured as part of the failover group referenced in the 
session monitor cluster configuration. The failover group must be configured before the 
session monitor cluster. (For information on configuring a failover group, see Chapter 6: 
"Configuring Failover'on page 87.) 

To replicate the session table to all the members of a failover group, you can use the 
following commands. 



Note: When using a session monitor cluster, the RADIUS client must be configured to 
send the RADIUS accounting messages to the failover group's virtual IP address. 



Proxy traffic can be routed to any of the machines in the cluster. 



Note: Each member of the failover group must configured with the cluster commands to 
maintain the session table for RADIUS accounting messages. 



To configure session monitor cluster parameters: 

SGOS# (config) session-monitor 



□ 



The following subcommands are available: 



SGOS# (config 
SGOS# (config 

SGOS# (config 
SGOS# (config 
SGOS# (config 



session- 

session- 

session- 

session- 

session- 



monitor) 

monitor) 

monitor) 

monitor) 

monitor) 



cluster {enable | disable} 
cluster group-address IP_address 



cluster port port_number 
cluster grace-period seconds 



cluster synchronization-delay seconds 
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Table 1 1 -2. Session Monitor Cluster Command Descriptions 



Command 


Option 


Description 


cluster 


enable | 
disable 


Enable or disable (the default) clustering on a failover group. 
The group address must be set before the cluster can be 
enabled. 


cluster group-address 
| no group -address 


IP_address 


Set or clear (the default) the failover group IP address. This 
must be an existing failover group address. 


cluster port 


port number 


Set the TCP/IP port for the session replication control. The 
default is 55555. 


cluster 

synchronization -del ay 


seconds 


Set the maximum time to wait for session table 
synchronization. The default is zero; the range is from 0 to 2 
A 31 -1 seconds. During this time evaluation of 
$ ( session . username) is delayed, so proxy traffic might 
also be delayed. 


cluster grace-period 


seconds 


Set the time to keep session transactions in memory while 
waiting for slave logins. This can be set to allow session table 
synchronization to occur after the synchronization-delay has 
expired. The default is 30 seconds; the range is 0 to 2 A 31-1 
seconds. 



Configuring the Session Monitor 

The session monitor commands set up session monitoring behavior. If using session- 
monitor clustering, these commands must be invoked on all systems in the failover group. 

To configure the session monitor: 

1. At the (config) prompt: 

SGOS# (config) session-monitor 

SGOS# (config session-monitor) disable | enable 
SGOS# (config session-monitor) max-entries integer 
SGOS# (config session-monitor) timeout minutes 



Table 11-3. Session Monitor Configuration Command Descriptions 



Command 


Option 


Description 


enable | disable 




Enable or disable (the default) session monitoring 


max entries 


integer 


The maximum number of entries in the session table. 
The default is 500,000; the range is from 1 to 2,000,000. 
If the table reaches the maximum, additional START 
messages are ignored. 


timeout 


minutes 


The amount of time before a session table entry 
assumes a STOP message has been sent. The default is 
120 minutes; the range is from 0 to 65535 minutes. Zero 
indicates no timeout. 
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2. (Optional) To view the session-monitor configuration, you can either use the 

session-monitor view command or the config show session-monitor command. 

SGOS# (config) show session-monitor 

General : 

Status : enabled 

Entry timeout: 120 minutes 

Maximum entries: 500000 

Cluster support : enabled 

Cluster port: 55555 

Cluster group address: 10.9.17.159 

Synchronization delay: 0 

Synchronization grace period: 30 

Accounting protocol : radius 

Radius accounting: 

Listen ports : 

Accounting: 1813 
Responses : Enabled 
Authentication: Enabled 
Shared secret: ************ 

Creating the CPL 

Be aware that the examples below are just part of a comprehensive authentication policy. 
By themselves, they are not adequate. 



Note: Refer to Volume 11: Content Policy Language Guide for details about CPL and how 
transactions trigger the evaluation of policy file layers. 



□ In this example, the SG appliance is using the session table maintained by the session 
monitor for authentication. 

<proxy> 

allow authenticate ( session) 

where s e s s i on is a policy substitution realm that uses $ (session. use r name ) in 
building the username. (For information on creating a Policy Substitution realm, refer 
to Volume 5: Securing the Blue Coat SG Appliance.) 

Notes 

□ The session table is stored entirely in memory. The amount of memory needed is 
roughly 40MB for 500,000 users. 

□ The session table is kept in memory. If the system goes down, the contents of the 
session table are lost. However, if the system is a member of a failover cluster, the 
current contents of the session table can be obtained from another machine in the 
cluster. The only situation in which the session table is entirely lost is if all machines in 
the cluster go down at the same time. 

□ The session replication protocol replicates session information only; configuration 
information is not exchanged. That means that each SG appliance must be properly 
configured for session monitoring. 

□ The session replication protocol is not secured. The failover group should be on a 
physically secure network to communicate with each other. 



142 



Chapter 1 1 : Configuring the SG Appliance as a Session Monitor 



□ The session monitor requires sufficient memory and at least lOOMb-per-second 
network links among the cluster to manage large numbers of active sessions. 

□ The username in the session table is obtained from the Calling-Station-ID attribute in 
the RADIUS accounting message and can be a maximum of 19 bytes. 
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The Blue Coat SG Client enables users to benefit from accelerated application delivery 
directly to their desktops. This allows mobile users or users in small branch offices — 
where it might not be cost-justifiable to deploy an acceleration gateway — to enjoy 
improved networked application access. 

For more information about the SG Client, see one of the following sections: 

□ "Overview" on page 146 

□ "Software and Hardware Requirements" on page 149 
a "Understanding ADN Details" on page 149 

□ "Configuring Client Settings" on page 151 

□ "Configuring the Client Manager" on page 156 

□ "Configuring from the Command Line" on page 159 

□ "Making the SG Client Software Available to Users" on page 161 
a "Using the SG Client" on page 171 

□ "Troubleshooting Tips for Administrators" on page 180 

□ "Licensing" on page 182 
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Overview 

Before implementing the SG Client in your enterprise, you should understand the 
following concepts: 

□ "Understanding the Terminology" on page 146 

□ "SG Client Features and Benefits" on page 147 

□ "Understanding SG Client Deployment" on page 148 

Understanding the Terminology 

The following figure illustrates the terminology discussed in this chapter: 




Blue Coat SG 
Concentrator and 
SG Client Manager 



Corporate 

WAN 



«8 






Small Branch 
Office 

SG Client Users 




Data 

Center 



Mobile SG Client 
Users 



The SG Client typically connects to a concentrator, which is a Blue Coat SG appliance that is 
usually located in a data center. The SG Client connection over the Internet is assumed to 
use Virtual Private Networking (VPN). 

The concentrator receives inbound ADN tunnels from the SG Client and serves as a front 
end for data center resources for which it provides acceleration services. 

To use the SG Client, you must configure SG appliances for the following roles: 

□ Concentrator 



An SG appliance, usually located in a data center, that provides access to data center 
resources, such as file servers. 

□ Client Manager 

This appliance provisions the SG Client software to users, and maintains the software 
and the client configuration on all clients in the ADN network. 

You configure the Client Manager as discussed in "Configuring the Client Manager" 
on page 156. 



146 




Chapter 12: Configuring and Using the SG Client 



□ ADN manager and backup manager (not shown in the preceding figure) 

Every ADN network must have an ADN manager, which is responsible for publishing 
the routing table to SG Clients (and to other SG appliances). Although not required. 
Blue Coat recommends configuring an ADN backup manager, which takes over for the 
ADN manager in the event it becomes unavailable. 



Note: The Client Manager can be any appliance in the ADN network, including a 

concentrator, the ADN manager, or backup manager. For example, the Client 
Manager could also be the ADN manager but that is not a requirement. 



To configure an ADN manager and backup manager, see "Defining the ADN 
Manager" on page 19. 

SG Client Features and Benefits 

The following table discusses features and benefits of the SG Client: 

Table 12-1 . SG Client Features and Benefits 



Feature 


Benefit 


Common Internet File System (CIFS) 
acceleration 


The SG Client significantly enhances Wide Area 
Network (WAN) file service delivery, improving user 
productivity by implementing the following: 

• Client object caching, which enables clients to get 
previously-obtained data from cache rather than 
across the WAN. 

• CIFS protocol optimization, which improves 
performance by consolidating data forwarded across 
the WAN. 


Connect from anywhere 


The SG Client enables any user to remotely connect to 
an ADN network. 


ADN optimization 


Uses gzip compression to improve bandwidth 
utilization for TCP applications. 


Centralized management and 
distribution 


Administrators use a particular SG appliance 
designated as the Client Manager to download to 
clients SG Client software and configuration updates. 


Load balancing and failover 


Enables you to efficiently use your ADN network as a 
robust infrastructure for clients. 


Client statistics 


Provides users with real-time performance data. 
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Understanding SG Client Deployment 

The SG Client software is deployed in two basic steps: the administrator configures the 
Client Manager to install and configure the client, then the user (or administrator) installs 
the client. After installation, the client connects to an appliance in the ADN network. The 
following sections discuss this process in more detail. 

Administrator Configuration Tasks 

The administrator configures the following: 

1. Sets up an ADN manager, backup manager, and configures the ADN network as 
discussed elsewhere in this book. 

2. Configures an SG appliance as the Client Manager as discussed in "Configuring the 
Client Manager" on page 156. 

The Client Manager must be licensed as discussed in "Licensing" on page 182. 

The Client Manager is the location from which users download the SG Client 
software, software updates, and configuration updates. 

3. Sets up the SG Client configuration (such as CIFS and ADN) as discussed in 
"Configuring Client Settings" on page 151. 

4. Provisions the SG Client software to users in one of the ways discussed in this chapter. 

For more information, see "Making the SG Client Software Available to Users" on 
page 161. 

Client Installation Tasks 

The SG Client deployment process can be summarized as follows: 

1. A user obtains the SG Client software, either from the Client Manager or pre-installed 
by an administrator some other way. 



Note: Installation methods are discussed in "Making the SG Client Software 

Available to Users" on page 161. 



To download the SG Client software from the Client Manager, the user must go to a 
URL provided by the administrator. 

When the user connects to the Client Manager using the URL, the user runs a setup 
application (SGClientSetup . exe) that in turn downloads and starts a Microsoft 
Installer (SGClientSetup .ms i). 



Note: To run SGClientSetup . exe and SGClientSetup .ms i, the user must be in the 

Administrators group on the machine. 
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2. After installing the SG Client software, the user must reboot the machine to use the 
software. 

3. Periodically, the SG Client polls the Client Manager for changes to the SG Client 
software and configuration. 



Note: Every software or configuration update requires the client to reboot their 

machine for the update to take effect. 



Software and Hardware Requirements 

The SG Client currently requires Microsoft Windows XP Professional or Home Edition, 
Service Pack 2 or later (32-bit version only; the 64-bit operating system is not supported). 



Note: Blue Coat highly recommends users apply all the latest hot fixes available 

from Microsoft Windows Update. 



The SG Client requires a machine with: 

□ Hard drive with 5MB available for SG Client software installation, up to 40MB for 
logging, and an additional 1.5GB available space (minimum) for CIFS object caching, 
5GB or more available recommended. 

The CIFS object cache is stored on the system root volume. If there is 1GB or less 
available space for the cache, the client will not cache CIFS objects, such as directory 
listings and file contents. 

□ Processor — Minimum, 500 megahertz (MHz) processor, such as the Intel family, AMD 
family, or compatible processor. 

Recommended, 750MHz or faster processor. 

□ RAM — 256MB minimum, 512MB or more recommended. 

Understanding ADN Details 

This section discusses the ADN features supported by the SG Client in this release. 

General ADN Feature Support 

The SG Client supports the following ADN features: 

□ Gzip compression, which improves bandwidth utilization. 

□ CIFS protocol optimization and CIFS caching on the client. 

□ Load balancing and failover 

The SG Client makes two types of connections in the ADN network: the routing 
connection and the ADN tunneling connection. The routing connection obtains the 
routing table from the ADN manager or backup manager, and the tunneling connection 
transfers data to the ADN network. 

The SG Client first attempts to connect to the primary ADN manager to get routing 
information; if it is not available, the client attempts to connect to the backup ADN 
manager. If the backup ADN manager is also not available, the connection goes 
directly to its destination as a result oifail open, which is discussed next. 
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Assuming there is more than one active SG appliance in the ADN network, the SG 
Client randomly picks an appliance from the list of appliances in the routing table and 
iterates through the list until it finds an active appliance. 

Randomly choosing an appliance — assuming there is more than one — achieves 
simple load balancing. Iterating through the list of appliances achieves failover. If no 
appliance is active, the connection goes directly to its destination as a result of fail 
open, which is discussed next. 

□ Fail open, which means that if all client connections to concentrators fail for any 
reason, the client opens a connection directly to a destination, such as a CIFS server. 

Client connections that do not go through a concentrator are not accelerated and 
remain unaccelerated as long as the connection is open (that is, until the connection is 
closed by the application). 

After a concentrator becomes available, new connections are accelerated. 

Configuring Plain Connections 

To use the SG Client in your ADN network, the ADN manager's listening mode must be 
configured for Plain Only, Plain Read-Only, or Both, as discussed in "Securing Connections" 
on page 33. 

□ Use the following guidelines to configure the Manager Listening Mode: 

• Choose Plain Read-Only if all SG appliances in the ADN network use SGOS 
version 5.1.4 — where all appliances support secure routing, and you have chosen 
to utilize secure routing on those SG appliances. 

This setting means that users who connect to the plain port are not allowed to 
advertise routes to the ADN network. 

• Choose either Plain Only or Both as appropriate if you have some SG appliances 
that are not using secure routing (for example, SG appliances running SGOS 
5.1.3). 

□ Use the following guidelines to set Tunnel Listening mode on all SG appliances in the 
ADN network: 

• Choose Plain to enable the SG Client to connect to the appliance in cases where 
you do not secure any ADN connections between SG appliances. 

• Choose Both to enable the SG Client to connect to the appliance in cases where 
you do use secure connections for some or all SG appliances. 



Note: The Secure Outbound Mode options have no impact on the SG Client. 



About Internet Gateways 

The SG Client ignores Internet Gateway settings; however, if you want to route all SG 
Client traffic through a concentrator, you can configure the concentrator to publish all 
addresses as discussed in "Managing Server Subnets and Enabling an Internet Gateway" 
on page 24. 
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Configuring Client Settings 

This section discusses how to configure the settings that affect SG Client configuration. 
Available settings follow: 

□ General settings — Software update interval, TCP window size, and maximum 
percentage of client disk space to allocate for object caching. See "Configuring General 
Client Settings" on page 151. 

□ CIFS settings — Disabling CIFS or enabling CIFS with options for write-back and 
directory cache time. See "Configuring Client CIFS Settings" on page 153. 

□ ADN settings — Primary and backup ADN manager IP addresses and port, excluded 
subnets, and included or excluded ports. See "Configuring Client ADN Settings" on 
page 154. 

Important: Changes you make to the client configuration are sent to clients at the next 
software update interval. After a configuration change, the user is required to reboot the 
client machine for the change to take effect. 

Configuring General Client Settings 

This section discusses how to configure the following client settings: 

□ SG Client software update interval 

□ TCP window size 

If you know the bandwidth and round-trip delay, the TCP window size you should 
use is approximately 2 * bandwidth * delay. For example, if the bandwidth of the 
link is 8 Mbits/sec and the round-trip delay is 0.75 seconds: 

TCP window size = 2 * 8 Mbits/sec * 0.75 sec = 12 Mbits = 1.5 Mbytes 

The setting in this example would be 1572864 bytes. This number goes up as either 
bandwidth or delay increases, and goes down as they decrease. Because the 
bandwidth and delay for SG Client users can vary. Blue Coat recommends you test SG 
Client performance in a controlled environment before deciding on a TCP window 
size value to use in production. 

□ Maximum percentage of client disk space to use for object caching. Regions of files 
that are read or written by the client are placed in the cache. Object caching applies to 
both read and write file activities. Also, the caching process respects file locking. 



Note: In this release, the object cache is not encrypted. 



You can set the maximum percentage of total disk space (as opposed to available disk 
space) the SG Client allocates to the object cache. The SG Client always leaves at least 
1GB of available disk space on the client machine's system root volume. 

Following is a summary of how object caching works on the client: 

a. The SG Client starts. 

b. The user requests a cacheable object, such as a file. 

c. The SG Client allocates sufficient disk space on the system root volume to 
cache the object — up to the limit set by the administrator. 

In other words, if the client machine's system root volume has 100GB of total 
space and the administrator configures the object cache to use a maximum of 10%, 
the SG Client allocates up to 10GB for the object cache. 
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However, if the maximum cache size leaves less than 1GB of available disk space, 
the cache size is further limited. Continuing this example, if the client has only 
9GB of available space, the maximum cache size is 8GB instead of 10GB. 

d. If any single object (such as a file) exceeds the maximum cache size, that 
object is not cached. 

To continue the preceding example, if the maximum size of the object cache is 
10GB, and the client requests a file that is 11GB in size, that file is not cached. 

e. If the object cache is full, objects are expired from the cache based on a 
number of criteria, such as unopened files and oldest objects first. 

To configure general client settings: 

1. Log in to the Management Console as an administrator. 

2. In the left pane, click SG Client > Client Configuration. 

3. In the right pane, click the General tab. 



4. On the General tab page, enter the following information: 
Table 12-2. Configuring General Client Settings 



Field 


Description 


Update interval 


Enter the frequency, in minutes, for clients to check the 
Client Manager for updated SG Client software or 
configuration updates. 

Default is 120. Valid values are between 10 — 432000 (that 
is, 300 days). 

Note: Updating SG Client software or configuration 
requires the client to reboot the machine. 


TCP window size 


Enter the number of bytes allowed before 
acknowledgement (the value must be between 8192 and 
4194304). Default is 65536. 


Maximum percentage of disk 
space to use for object caching 


Maximum percentage of client disk space to use for 
caching objects, such as CIFS objects. Valid values are 1 — 
90; default is 10. 

Note: The cache leaves at least 1GB available space on the 
system root volume. For more information, see 
"Configuring General Client Settings" on page 151. 



5. Select Apply to commit the changes to the SG appliance. 
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Configuring Client CIFS Settings 

This section discusses how to configure the following: 

□ Enable or disable CIFS acceleration 

□ Enable or disable write-back 

□ Set the directory cache time 

To configure CIFS settings: 

1. Log in to the Management Console as an administrator. 

2. In the left pane, click SG Client > Client Configuration. 

3. In the right pane, click the CIFS tab. 

4. On the CIFS tab page, enter the following information: 
Table 12-3. Configuring Client Settings for CIFS 



Item 


Description 


Enable CIFS acceleration check 
box 


• Select the check box to enable CIFS acceleration for clients. 

• Clear the check box to disable CIFS acceleration. If you clear the check box, 
the other options on this tab page are unavailable. 

For more information about CIFS acceleration, see "SG Client Features and 
Benefits" on page 147. 


Write back 


Determines whether or not users can continue sending data to the appliance 
while the appliance is writing data on the back end. 

• Click Full to enable write-back, which in turn makes the local SG Client 
proxy appear to the user as a file server; in other words, the local SG Client 
proxy constantly sends approval to the client and allows the client to send 
data while the back end takes advantage of the compressed TCP connection. 

• Click None to disable write-back. Disabling write-back can introduce 
substantial latency while clients send data to the appliance and wait for 
acknowledgement before sending more data. 

One reason to set this option to None is the risk of data loss if the link from 
the branch to the core server fails. There is no way to recover queued data if 
such a link failure occurs. 


Directory cache time field 


Number of seconds for directory listings to remain in the client's cache. 



5. Select Apply to commit the changes to the SG appliance. 
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Configuring Client ADN Settings 

This section discusses how to configure the following: 

□ ADN manager settings: 

• Primary and backup ADN manager IP addresses 

• ADN manager port 

□ ADN rules settings: 

• Excluded subnets 

Adds or removes subnets from the list of subnets not included in ADN tunnels. 
Assuming SG Clients can connect to an SG appliance that can optimize traffic to 
the destination address, this is the list of IP addresses and subnets that bypass 
ADN tunneling on the way to the destination. 

• Include and exclude ports 

Includes or excludes TCP ports in ADN tunnels. Assuming SG Clients can 
connect to an SG appliance that can optimize traffic to the destination address, 
this setting determines ports accelerated (or not accelerated) for clients. You can 
use either the excluded ports list or included ports list, but not both. 

The include and exclude ports list are advanced settings that limit the traffic that 
is accelerated by the ADN network. Because the ADN manager sets options for 
both its peers in the ADN network and for SG Clients, you can use the include or 
exclude ports list to fine-tune the way SG appliances interact with the SG Client. 

For example, if you know that SG Client traffic over particular ports is not 
compressible, you can put those ports in the exclude ports list. Blue Coat strongly 
recommends you test the include/ exclude ports settings in a controlled 
environment before using them in production because improper settings can have 
an adverse impact on performance. 

Configuring Client ADN Manager Settings 

To configure client ADN Manager settings: 

1. Log in to the Management Console as an administrator. 

2. In the left pane, click SG Client > Client Configuration. 

3. In the right pane, click the ADN Manager tab. 



4. On the ADN Manager tab page, enter the following information: 
Table 1 2-4. Configuring Client Settings for ADN Manager 



Field 


Description 


ADN Manager 


Enter the primary ADN manager's IP address. The ADN 
manager tracks and advertises the routes to the 
appliances it knows about. 

The SG Client obtains the routing table from the ADN 
manager. 
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Table 1 2-4. Configuring Client Settings for ADN Manager (Continued) 



Field 


Description 


Backup Manager 


Enter the backup ADN manager's IP address. 
Configuring a backup ADN manager is optional but 
recommended. 

If the ADN manager becomes unavailable for any reason, 
the backup ADN manager takes over the task of 
advertising routes to all ADN nodes — including SG 
Clients. 


Port 


Enter the ADN managers' plain listen port. 



5. Select Apply to commit the changes to the SG appliance. 



Configuring Client ADN Rules Settings 

To configure client ADN Manager settings: 

1. Log in to the Management Console as an administrator. 

2. In the left pane, click SG Client > Client Configuration. 

3. In the right pane, click the ADN Rules tab. 

4. On the ADN Rules tab page, in the Excluded Subnets section, do one of the following: 

• To add excluded subnets (in other words, to cause SG Client traffic from these 
subnets to bypass the ADN tunnel), click Add. 

In the Add IP/Subnet dialog box, enter the following information and click OK 
when you're done: 

• IP / Subnet Prefix field: Enter either an IP address or an IP address and subnet 
in Classless Inter-Domain Routing (CIDR) notation (for example, 

192 . 168 . 0 . 1 / 16 ). 

• Subnet Mask field: Use this field only if you entered an IP address in the 
preceding field (in other words, if you used CIDR notation in the preceding 
field, you do not need to enter a value in this field). 

• To remove excluded subnets, click the subnets you want to remove and click 
Remove. You are required to confirm the action. 

• To clear all excluded subnets (in other words, to cause SG Client traffic from all IP 
addresses and subnets to be tunneled), click Clear all. You are required to confirm 
the action. 



5. On the ADN Rules tab page, in the Ports section, enter the following information: 
Table 12-5. Configuring Included or Excluded Ports 



Item 


Description 


Exclude 


Client traffic from specified ports is not routed through 
the ADN tunnel. All other traffic is accelerated. 

Valid values: Comma-separated list of ports and port 
ranges (no spaces, separated by a dash character). 
Example: 22 , 88 , 443 , 993 , 995 , 1352 , 1494 , 1677 , 
3389,5900 
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Table 12-5. Configuring Included or Excluded Ports (Continued) 



Item 


Description 


Include 


Client traffic from specified ports is routed through the 
ADN tunnel and therefore accelerated. All other traffic 
bypasses the tunnel and is therefore not accelerated. 
Valid values: Comma-separated list of ports and port 
ranges (no spaces, separated by a dash character). 
Example: 80,13 9,445,8080-8088 



Note: The include and exclude ports lists are advanced settings that limit the traffic 
that is accelerated by the ADN network. For more information, see "Configuring 
Client ADN Rules Settings" on page 155. 

To cause all traffic to be accelerated by the ADN network, click either option and 
delete all the ports in the list. 



6. Select Apply to commit the changes to the SG appliance. 

Configuring the Client Manager 

You must configure one SG appliance in your ADN network as the Client Manager, 
meaning it is responsible for provisioning the SG Client software, software updates, and 
client configuration to SG Clients. The Client Manager must be licensed as discussed in 

"Licensing" on page 182. 

Note: The Client Manager can be a different appliance than the ADN manager or the 
backup ADN manager. In other words, you can configure the ADN manager or the 
backup ADN manager as the Client Manager, but it's not required. 

Setting an Appliance as the Client Manager 

To set an SG appliance as the Client Manager: 

1. Log in to the Management Console as an administrator. 

2. In the left pane, click SG Client > Client Manager. 

3. In the right pane, click the Client Manager tab. 

4. Select the Enable Client Manager checkbox. 

5. In the Client Manager section in the right pane, enter or edit the following 
information: 



Note: 

• Before you can enable an appliance to be the Client Manager, you must 
configure the ADN manager SG Clients will use. If you enable the Client 
Manager before you configure an ADN manager for clients, the following 
error displays when you attempt to apply the change: The ADN primary 
manager must be set prior to enabling the SG Client Manager. To 
configure the clients' ADN manager, see "Configuring Client ADN Manager 
Settings" on page 154. 

• License information displays below the check box. For more information, see 
"Licensing" on page 182. 



156 



Chapter 12: Configuring and Using the SG Client 



Table 12-6. Client Manager Section 



Item 


Description 


Host 


Specify the host from which users get the SG Client software, configuration, and updates as 
one of the following: 

• Use host from initial client request: ( Recommended .) Click this option if you want 
clients to download the SG Client software, configuration, and updates from the host 
from which the clients originally obtained the software and configuration. 

• Use host: Click this option only if you want to change the host from which clients 
download the SG Client software, configuration, and updates. Enter a fully-qualified 
host name or IP address only; do not preface it with http : // or https : / /or 
downloads will fail. 

In other words, this option enables you to change the host from which currently- 
installed clients obtain future software and configuration updates. Use caution when 
selecting this option because if clients are unable to connect to the host you enter in the 
adjacent field, new installations from the Client Manager and updates to existing 
installations fail. 

Note: Blue Coat recommends you enter a fully-qualified host name. If you enter either 
an unqualified host name or IP address and change the IP address later, connections to 
all currently-connected clients are dropped. 


Port field 


Enter the port on which the Client Manager listens for requests from clients. Default is 8084. 


Keyring list 


Click the keyring you want to use when clients connect to the Client Manager. 



6. Select Apply to commit the changes to the SG appliance. 



After you apply the changes, the Client Components section displays a summary of 
the information you selected, as follows: 

Table 12-7. Client Components section 



Item 


Description 


Client setup 


Displays the URL from which users will download the SG 
Client setup application. The setup application 
(SGClientSetup . exe) downloads the Microsoft Installer 
(MSI) — named SGClientSetup .msi — to the client. 

If you want users to install the SG Client software from the 
Client Manager, provide this URL to them. To install the 
software this way, the user must have administrative 
privileges on the client machine. 


Client install MSI 


Displays the URL from which SGClientSetup . exe 
downloads SGClientSetup. msi. 

If you want to install the SG Client software on client 
machines silently or using Group Policy Objects (GPO), use 
SGClientSetup .msi. 


Client configuration 


Displays the URL from which the SG Client installer will 
download the client configuration file 
(SGClientConf ig . xml). 


Client configuration last 
modified 


Displays the most recent date and time 
SGClientConf ig . xml was updated on the Client 
Manager. 
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Uploading the SG Client Software to the Client Manager 

This section discusses how to upload updated SG Client software to the Client Manager 
so it can make the latest SG Client software available to install or to update on client 
machines. 

Important: After you update the Client Manager's SG Client software, whenever users 
connect using the SG Client, they must update their SG Client software. As a result, users 
must reboot their machines to use the updated software. 

To upload the SG Client software to the Client Manager: 

1. If necessary, copy the sg client . car file to a location that is accessible from the 
machine on which you're running the Management Console. 

That is, if you want to upload the SG Client software from your local file system or 
from a network share drive (as opposed to uploading it from a remote URL), you 
must copy the SG Client . car file to an accessible location. 

2. Log in to the Management Console as an administrator. 

3. In the left pane, click SG Client > Client Manager. 

4. In the right pane, click the Client Software tab. 

On the Client Software tab page, the Current SG Client Software section displays 
information about the SG Client software this Client Manager is currently using. 

5. In the Install SG Software section, from the Install SG Client software from list, click one 
of the following: 

• Remote URL: Upload the SG client . car file from a location specified by a URL 
in the following format: 

https : / /host -.port/ sgclient/ SGC1 ient_t imest amp . car 
For example, 

http : / /mysg . example . com: 8004/ sgclient/SGClient_t imest amp . car 
Follow the prompts on your screen to complete the upload. 

• Local file: Upload the SG Client software from a location accessible by the 
machine on which you're running the Management Console. Follow the prompts 
on your screen to complete the task. 

6. Click Install. 

You are required to confirm the action. Remember that any software or configuration 
updates require SG Client users to download the updates the next time they connect 
to the ADN network. Any configuration or software update requires the user to 
reboot their machine for the update to take effect. 

7. Follow the prompts on your screen to complete the download. 



Note: A compatibility check is performed on the SG Client version you just 

uploaded. If the upload fails, you must upgrade your SGOS version before you can 
upload the SG Client . car file. 
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Configuring from the Command Line 

Configuring General Client Settings 

To configure general client settings: 

1. At the # (conf ig) command prompt, enter sg-client. 

2. Configure general client settings: 

#(config sg-client) max-cache-disk-percent percentage 
#(config sg-client) software-upgrade-path url 
#(config sg-client) tcp-window- size bytes 
#(config sg-client) update- interval minutes 
#(config sg-client) view 

Configuring CIFS Client Settings 

To configure CIFS client settings: 

1. At the # (conf ig) command prompt, enter sg-client. 

2. At the # (conf ig sg-client) prompt, enter cifs. 

3. Configure CIFS settings: 

#(config sg-client cifs) directory-cache-time seconds 

#(config sg-client cifs) {disable | enable} 

#(config sg-client cifs) exit 

#(config sg-client cifs) write-back {full | none} 

#(config sg-client cifs) view 

Configuring ADN Manager Settings 

To configure ADN manager settings: 

1. At the # (conf ig) command prompt, enter sg-client. 

2. At the # (conf ig sg-client) prompt, enter adn. 

3. Configure ADN manager settings: 

#(config sg-client adn) primary-manager ip-address 
#(config sg-client adn) backup -manager ip-address 
#(config sg-client adn) manager-port plain-port 
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Configuring ADN Rules Settings 



To configure ADN rules settings: 



1 . 

2 . 

3. 



At the # (conf ig) command prompt, enter sg-client. 
At the # (conf ig sg-client) prompt, enter adn. 



Configure ADN manager settings: 

#(config sg-client adn) port-list {exclude -ports | include-ports} 
#(config sg-client adn) {exclude-ports | include-ports} {port-list | 
port -range} 

#(config sg-client adn) exclude -subnets 



#(config sg-client adn exclude -subnets) 
subnet_prefix [/prefix length] 

#(config sg-client adn exclude -subnets) 
#(config sg-client adn exclude -subnets) 
#(config sg-client adn exclude -subnets) 



{ add | remove } 

clear 

exit 

view 



#(config sg-client adn) exit 



Setting the Client Manager 

To configure the Client Manager: 

1. At the # (conf ig) command prompt, enter sg-client. 

2. Enable this appliance as the Client Manager: 

#(config sg-client) enable 



Note: Before you can enable an appliance to be the Client Manager, you must 

configure the ADN manager SG Clients will use. If you enable the Client Manager 
before you configure an ADN manager for clients, the following error displays: The 
ADN primary manager must be set prior to enabling the SG Client 
Manager. To configure the clients' ADN manager, see "Configuring Client ADN Rules 
Settings" on page 155. 



3. Configure Client Manager settings: 

#(config sg-client) client-manager host { from-client-address | Kip- 
address | hos t>} 

# (config sg-client) client-manager install-port port 
#(config sg-client) client-manager keyring keyring 

Loading the Software 

# (config sg-client) software-upgrade-path path-to-SGClient-car 
# (config) load sg-client-software 
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Making the SG Client Software Available to Users 

This section discusses how administrators can make the SG Client software available to 
users in any of the following ways: 

□ Interactive installations started from: 

• A command line on the user's machine 

• The Client Manager 

For more information, see "Setting Up Interactive Installations" on page 161 

□ Silent installations 

For more information, see "Setting Up Silent Installations and Uninstallations" on 
page 165 

□ Windows Group Policy Object distribution 

For more information, see "Using Group Policy Object Distribution" on page 170 



Note: For the user to run SGClientSetup . exe or SGClientSetup .msi, the user 

must be in the Administrators group on the client machine. 



Important: Do not rename SGClientSetup . msi because doing so causes future 

updates to fail. 

Do not edit SGClientConf ig .xml on the client machine because doing so causes 
unpredictable results in future configuration updates. 



Setting Up Interactive Installations 

Users can install the SG Client software either by downloading SGClientSetup . exe from 
the Client Manager, or manually by running SGClientSetup .msi from a command line, 
as shown in the following table: 

Table 12-8. SG Client Installation Options 



Option 


Description 


Install from Client Manager 


Provide users the URL to SGClientSetup . exe, which displays 
on the Management Console's SG Client > Client Manager, 
Client Manager tab page. 

SGClientSetup . exe downloads and runs 
SGClientSetup .msi on the client machine. Users see the 
installation in progress and have the option of canceling the 
installation. 

For more information about this installation method, see 
"Interactive Installations From the Client Manager" on 
page 162 . 
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Table 12-8. SG Client Installation Options (Continued) 



Option 


Description 


Install manually 


To install the SG Client using SGClientSetup . msi, users must 
first download it to the client machine, then execute it from the 
command line as discussed in "Interactive Manual 
Installations" on page 164. 

Note: For a complete discussion of SGClientSetup .msi 
command-line parameters, see "Setting Up Silent 
Installations and Uninstallations" on page 165. 



Note: Users who run the SG Client setup application must be in the Administrators 

group on the client machine. 



Interactive Installations From the Client Manager 

To interactively install the SG Client software from the Client Manager, the user must be in 
the Administrators group on the client machine. 

To enable users to run SGCIientSetup.exe from the Client Manager: 

Provide users the URL to SGClientSetup . exe on the Client Manager. 

The URL displays in the Management Console on the SG Client > Client Manager, Client 
Manager tab page. 

For users to install the SG Client using this method: 

1. You provide the URL or location from which the user can access SGClientSetup . exe. 

2. The user clicks the URL in an e-mail or enters it in the browser's location field. 

3. SGClientSetup . exe starts the setup application — SGClientSetup .msi — that installs 
the SG Client software. 

The following dialog box displays if you attempt the download using Internet 
Explorer 6: 




4. Click Run. 
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The following dialog box displays if you attempt the download using Internet 
Explorer 6: 



Internet Explorer - Security Warning 



The publisher could not be verified. Are you sure you want to run this 
software? 

Name: SGClient5etup.exe 
Publisher: Unknown Publisher 





This file does not have a valid digital signature that verifies its publisher. You 
should only run software from publishers you trust. How can I decide what 
software to run? 



Note: The preceding dialog box displays because SGClientSetup . exe is not 

signed. This is due to SGClientSetup . exe being unique to each Client Manager, 
which in turn makes signing it by a recognized certificate authority difficult. 



5. Click Run. 

The SG Client software installation begins and while it's being downloaded, a 
progress dialog box similar to the following displays: 




When installation is complete, a dialog box with two options displays: 

• Click Now to reboot your machine immediately. 

• Click Later to reboot your machine at a later time. 

You should choose this option if you have work you need to save before 
rebooting. 
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Interactive Manual Installations 

To enable users to manually install the SG Client software: 

Provide a location from which the user can download SGClientSetup .msi to the client 
machine; for example, provide the user the URL to the Client Manager. 



Important: Do not rename SGClientSetup . msi because doing so causes future 

updates to fail. 

Do not edit SGClientConf ig .xml on the client machine because doing so causes 
unpredictable results in future configuration updates. 



For users to install the SG Client using this method: 

1. The user downloads SGClientSetup . msi to a location on the local file system. 

2. The user does either of the following: 

• Clicks Start > Run, then enters the command shown in step 3. 

• Opens a DOS command prompt window and changes to the directory to which 
they downloaded SGClientSetup .msi 

3. The user enters the following command: 

pa th\ SGClientSetup . msi BCSI_UPDATEURL=url - to- con f ig . xml 

where path is the absolute file system path to SGClientSetup . msi (if necessary), url - 
t o-config . xml is the URL to SGClientConf ig . xml on the Client Manager. 

This URL displays in the Management Console in SG Client > Client Manager, Client 
Manager tab page as discussed in "Configuring the Client Manager" on page 156. 

For example, 

SGClientSetup . msi BCSI_UPDATEURL=http : //mysg . example . com : 8084 / 
sgclient/ SGClientConf ig . xml 



Note: Other command-line parameters are available. For a complete list, see 

"Setting Up Silent Installations and Uninstallations" on page 165. 



4. The installation proceeds as discussed in steps 4 and following "Interactive 
Installations From the Client Manager" on page 162. 
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Setting Up Silent Installations and Uninstallations 

This section discusses how to silently install or uninstall the SG Client. 

See one of the following sections: 
a "Parameters for Silent Installations" on page 165 

□ "Command for Silent Uninstallations" on page 167 

□ "Examples Installations and Uninstallations" on page 167 

Important: Do not rename SGClientSetup . msi because doing so causes future 
updates to fail. 

Do not edit SGC1 ientConf ig . xml on the client machine because doing so causes 
unpredictable results in future configuration updates. 



For information about distributing the SG Client software using Group Object Policy, skip 
this section and see "Using Group Policy Object Distribution" on page 170. 

Parameters for Silent Installations 

The following table shows command-line parameters to use with SGClientSetup . msi for 
silent installations. For examples, see "Examples Installations and Uninstallations" on 
page 167. 

Silent Installation Usage 

SGClientSetup. msi [/qr|/qn] BCSI_UPDATEURL= url REINSTALL=ALL 
RE INS TALLMODE = vamus [ AUTOUPDATED I SABLED= 0 | 1] 

[AUTOUPDATEPROHIBITED=0 | 1] [FORCEREBOOT= {yes | no} | {y|n}] 

[REBOOTTIME=secs] t/l*v logfile] 

Silent Installation Parameters 

The following table shows the meanings of the parameters that can be used for silent 
installations; for examples, see "Examples Installations and Uninstallations" on page 167: 

Table 12-9. Parameters for Silent SG Client Installations 



Parameter 


Argument 


Description 


/qr | /qn 




/qr (interactive, default) enables the user to see and interact 
with the installer, and to cancel the installation. 

/qn (totally silent) prevents the user from seeing or 
interacting with the installer, and from canceling the 
installation. 

Note: Because this is an msiexec command, other options 
are available. Enter msiexec at a command prompt for 
more information about other options. 


BCSIJJPDATEURL 


url 


URL to SGC1 ientConf ig .xml on the Client Manager, 
which you can find as discussed in "Configuring the 
Client Manager" on page 156, entered in the following 
format: 

https : / / client-manager-host : client - manager- 
port/ sgclient/ SGC1 ientConf ig . xml 
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Table 12-9. Parameters for Silent SG Client Installations (Continued) 



Parameter 


Argument 


Description 


REINSTALL 


ALL 


Installs all SG Client components, whether they are already 
installed or not. 

ALL is the only supported parameter value in this release. 


REINSTALLMODE 


vamus 


Blue Coat recommends using vamus as the parameter value. 
Because this is an msiexec command, other options are 
available. For more information, see the description of this 
parameter at: http : / /msdn2 . microsof t . com/en-us/ 
library/ aa3 71182 . aspx 


AUTOUPDATEDISABLED 


0 1 1 


0 (default) means the SG Client automatically implements 
software and configuration updates at the frequency the 
administrator specified for software update interval in 
"Configuring General Client Settings" on page 151. 

1 means the SG Client checks for software and configuration 
updates and does the following: 

• Implements configuration updates when they are 
available. 

• Implements software updates only if the user manually 
requests an update. 

This setting enables you to test the SG Client installation 
before deploying it in production. 

In other words, before you deploy the SG Client in your 
enterprise, you might want to test it in a controlled manner 
with a small number of users. Doing so keeps clients from 
requesting updates immediately after installation. 

(Users can manually update the software and configuration 
as discussed in "Updating the SG Client Software and 
Configuration" on page 177. After the user manually 
updates the software and configuration, the SG Client 
software checks for updates at the interval you specified in 
"Configuring General Client Settings" on page 151.) 


AUTOUPDATEPROHIBITED 


0 1 1 


0 (default) means the SG Client automatically implements 
software and configuration updates at the interval the 
administrator specified for software update interval in 
"Configuring General Client Settings" on page 151. 

1 means only the SG Client configuration can be updated 
(automatically or manually), but the SG Client software 
cannot be updated. Use this setting if you want to distribute 
software updates in some way other than the Client 
Manager. 

Note: AUTOUPDATEPROHIBITED=l takes precedence over 
AUTOUPDATED I SABLED= 1 . 
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Table 12-9. Parameters for Silent SG Client Installations (Continued) 



Parameter 


Argument 


Description 


FORCEREBOOT 


yes | no 
y|n 


This setting controls whether or not Now or Later buttons 
display on the post-installation reboot dialog box. 
yes or y mean the dialog box displays without buttons. 
(However, if REBOOTTIME= 0, no dialog box displays.) 

no or n (default) mean a dialog box displays with two 
options: Now and Later, enabling the user to either reboot 
immediately, wait for the timer to expire (see the next 
parameter); or wait until a later time of their choosing. 


REBOOTTIME 


secs 


Number of seconds after the SG Client installation 
completes before the user's machine is rebooted. A value of 
0 means there is no timer; to the user, a value of 0 has 
slightly different meanings, depending on the value of 
FORCEREBOOT. For more information, see "Examples 
Installations and Uninstallations" on page 167. 

Default is 0. 


/hv 


logfile 


If you want the installation to be logged, enter the absolute 
file system path and file name of the log file. 



Command for Silent Uninstallations 

To silently uninstall the SG Client software, use the following command: 
msiexec /q /x { 4214C5ED-CCED-4360- 90C0-69764F3D0854 } 

Note: Users who have administrative privileges on their machines can also uninstall the 
SG Client using the Windows Control Panel's Add or Remove Programs application as 
discussed in "Uninstalling the SG Client Software" on page 179. 

Examples Installations and Uninstallations 

This section shows the following examples: 

□ "Example Installations" on page 167 
a "Example Uninstallation" on page 169 



Important: Do not rename SGClientSetup . msi because doing so causes future 
updates to fail. 

Do not edit SGClientConf ig .xml on the client machine because doing so causes 
unpredictable results in future configuration updates. 



Example Installations 

Example 1: Automated, interactive installation with manual software updates possible: 

SGClientSetup .msi /qr BCSI_UPDATEURL=https : / /mysg . example . com: 8084/ 
sgclient/SGClientConf ig . xml RE INS TALL = ALL REINSTALLMODE=vamus 
AUTOUPDATED I SABLED= 1 FORCEREBOOT=no REBOOTTIME=3 0 

The SG Client configuration is downloaded from the Client Manager at 

https : / /mysg . example . com: 8 084. The user sees the installation in progress and can 

cancel it. 
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autoupdated i sabled= l means that the SG Client does not implement software 
updates after the initial installation (it will, however, implement configuration 
updates). This setting enables you to test the SG Client software on a small scale 
without having to plan for client updates. 

(To get software updates manually and thereafter enable automatic updates, click 
Check for Updates on the Advanced tab page in the SG Client dialog box as discussed 
in "Updating the SG Client Software and Configuration" on page 177.) 

The reinstall and reinstallmode parameters make sure that all SG Client 
components install, which is useful in cases where you are recovering from an 
incomplete or previously-unsuccessful installation. 

After the installation is complete, the user has the following options: 

• Wait 30 seconds for the machine to reboot 

• Click Later on the dialog box to defer rebooting until a later time 

• Click Now on the dialog box to reboot immediately 

Example 2: Automated, interactive installation with no automatic software updates 
possible 

SGClient Setup . msi /qr BCSI_UPDATEURL=https : / /mysg . example . com : 8084/ 
sgclient/SGClientConf ig . xml REINSTALL=ALL REINSTALLMODE=vamus 
AUTOUPDATEPROHIBITED=l FORCEREBOOT=no REBOOTTIME=3 0 

The SG Client configuration is downloaded from the Client Manager at 

https : / /mysg . example . com: 8 084. The user sees the installation in progress and can 

cancel it. 

autoupdateprohibited=i means the SG Client cannot check for software updates 
after the initial installation; however, it will check for and implement configuration 
updates. Use this setting if you want to distribute software updates in some way other 
than the Client Manager. 

The reinstall and reinstallmode parameters make sure that all SG Client 
components install, which is useful in cases where you are recovering from an 
incomplete or previously-unsuccessful installation. 

After the installation is complete, the user has the following options: 

• Wait 30 seconds for the machine to reboot 

• Click Later on the dialog box to defer rebooting until a later time 

• Click Now on the dialog box to reboot immediately 
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Example 3: Automated, interactive installation 

SGClient Setup . msi /qr BCSI_UPDATEURL=https : / /mysg . example . com : 8084/ 
sgclient/SGClientConf ig . xml RE INS TALL = ALL REINSTALLMODE=vamus 
FORCEREBOOT=no REBOOTTIME=30 

The SG Client configuration is downloaded from the Client Manager at 
https : / /mysg . example . com: 8 084. The user sees the installation in progress and can 
cancel it. The reinstall and reinstallmode parameters make sure that all SG Client 
components install, which is useful in cases where you are recovering from an 
incomplete or previously-unsuccessful installation. 

After the installation is complete, the user has the following options: 

• Wait 30 seconds for the machine to reboot 

• Click Later on the dialog box to defer rebooting until a later time 

• Click Now on the dialog box to reboot immediately 

Example 4: Automated, interactive installation without a timer 

SGClientSetup .msi /qr BCSI_UPDATEURL=https : / /mysg. example . com: 8084/ 
sgclient/SGClientConf ig. xml RE INS TALL = ALL REINSTALLMODE=vamus 
FORCEREBOOT=no REBOOTTIME=0 

The SG Client configuration is downloaded from the Client Manager at 
https : / /mysg . example . com: 8 084. The user sees the installation in progress and can 
cancel it. The reinstall and reinstallmode parameters make sure that all SG Client 
components install, which is useful in cases where you are recovering from an 
incomplete or previously-unsuccessful installation. 

After the installation is complete, the user has the following options: 

• Click Later on the dialog box to defer rebooting until a later time 

• Click Now on the dialog box to reboot immediately 

Example 5: Totally silent installation, immediate reboot 

SGClientSetup .msi /qn BCSI_UPDATEURL=https : / /mysg . example . com : 8084/ 
sgclient/SGClientConf ig. xml REINSTALL=ALL REINSTALLMODE=vamus 
FORCEREBOOT=ye S REBOOTTIME=0 

The SG Client configuration is downloaded from the Client Manager specified at 
https : / /mysg . example . com: 8 084. The user does not see the installation in progress 
and cannot cancel it. The user's machine is rebooted immediately after the installation 
is complete. The reinstall and reinstallmode parameters make sure that all SG 
Client components install, which is useful in cases where you are recovering from an 
incomplete or previously-unsuccessful installation. 

Example Uninstallation 

msiexec /q /x { 4214C5ED-CCED-4360 - 90C0-69764F3D0854 } 
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Using Group Policy Object Distribution 

This section discusses how to distribute the SG Client software using Windows Group 
Policy Object (GPO). Only an experienced Windows administrator should attempt to 
complete the tasks discussed in this section. 

To distribute the SG Client software using GPO: 

1. Get an . msi transform tool, such as the Orca database editor. 

Orca is a table-editing tool available in the Windows Installer SDK that can be used to 
edit your .msi files. You can also use similar tools available from other vendors. 



Note: Blue Coat does not recommend a particular transform tool. 



For more information about Orca, see: 

http : / /support . microsof t . com/kb/2 559 05/en-us 

The remainder of this section assumes you use Orca. Consult the documentation 
provided with the transform tool you're using for vendor-specific instructions. 

2. Open SGClientSetup . msi. 



3. Right-click each of the following SG Client properties and change them as shown in 
the following table: 

Table 12-10. SG ClientSetup Transform Properties 



Property 


Action 


Value 


BCSI_UPDATEURL 


Add row 


URL to SGC1 ientConf ig . xml on the Client 
Manager, which you can find as discussed in 
"Configuring the Client Manager" on 
page 156, entered in the following format: 
https : / / client -manager - 
host : client-manager-port/ sgclient/ 
SGC1 ientConf ig . xml 


FORCEREBOOT 


Edit value 


y 



Note: Do not use any of the other parameters discussed in Table 12-9 on page 165 — 

in particular, reinstall and reinstallmode. Using these parameters will cause 
installations to fail. 



4. Generate the transformation. 
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Using the SG Client 

Note: This section is written from the point of view of users, not administrators. 

After the SG Client software is installed, it starts automatically when you start your 
machine. You don't have to do anything to enable it. 

The SG Client icon displays as follows in the Windows system tray: 



o 



You can access the SG Client software in any of the following ways: 
Table 12-11. Accessing the SG Client Software 



To perform this action... 


...Use these steps 


Open the SG Client dialog box 


• Double-click its icon in the system tray 

• Right-click or left-click its icon in the system tray, 
and, from the pop-up menu, click Open 


Enable the SG Client 


Right-click or left-click its icon in the system tray, 
and, from the pop-up menu, click Enable SG Client. 


Disable the SG Client 


• Right-click or left-click its icon in the system tray, 
and, from the pop-up menu, click Disable SG 
Client. 

• Open the SG Client, click the General tab, and 
then click Disable SG Client. 


Hide or display the icon 


Hide: Right-click or left-click its icon in the system 
tray, and, from the pop-up menu, click Hide Tray 
Icon. 

To cause the icon to display again, click Start > [All] 
Programs > Blue Coat > SG Client > SG Client. 
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When you open the SG Client, its dialog box displays as follows: 




b 



a 



c 



e 



f 



9 



h 



For more information about the indicated item, see one of the following sections: 

a. "Viewing Statistics and ADN Tunnels" on page 172 

b. "Troubleshooting the SG Client" on page 175 

c. "Finding Information About The SG Client" on page 177 

d. "Viewing Statistics and ADN Tunnels" on page 172 

e. "Troubleshooting the SG Client" on page 175 

f. "Viewing Statistics and ADN Tunnels" on page 172 

g. "Troubleshooting the SG Client" on page 175 

h. "Enabling and Disabling the SG Client" on page 174 

Viewing Statistics and ADN Tunnels 

The SG Client displays acceleration statistics, such as total bandwidth gain and bytes 
saved, and enables you to view current Application Delivery Network (ADN) tunnels. An 
ADN tunnel is a type of network connection that optimizes performance over a Wide Area 
Network (WAN). 

You can use this information to see how the ADN network performs in response to your 
actions or to troubleshoot problems. 

To view statistics and ADN tunnels: 

1. Double-click the SG Client icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > [All] Programs > 
Blue Coat > SG Client > SG Client.) 

The SG Client dialog box displays. 

2. In the SG Client dialog box, click the General tab. 
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The General tab page displays as follows: 




a 



f 



b 



9 



c 

d 



e 



Note: If you don't see a bar graph like in the preceding figure, the client might be 

disabled. Click Enable SG Client to enable the client. 



You have the following options: 

Table 12-12. Viewing ADN Statistics in the SG Client 



Item (see preceding 
figure) 


Steps 


a 


The graph at the top of the tab page displays the following: 

• Actual Usage: The sum of bytes data delivered after acceleration, in 
and out. 

• Total Demand: The estimated number of bytes requested, in and out. 
In other words, the estimated number of bytes transmitted if you 
had not installed the SG Client. 

The units of measure can be bytes, kilobytes, megabytes, or gigabytes, 
as appropriate. 


b 


The total bandwidth gained as a result of using the SG Client. 


c 


Number of bytes saved by using the SG Client (in other words, the 
number of bytes that would have been transmitted over the WAN if the 
SG Client was not installed). 


d 


The inbound bandwidth gained as a result of using the SG Client. 


e 


The outbound bandwidth gained as a result of using the SG Client. 


t 


You typically click View ADN Tunnels when instructed to do so by you 
network administrator or support organization. 


g 


To reset all statistics on this page to zero, click Reset Statistics. This 
does not affect network traffic into or out of your machine. 
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Enabling and Disabling the SG Client 

You can enable or disable the SG Client in any of the ways discussed in this section. 

Enabling the SG Client 

The SG Client is enabled when you boot your machine and remains enabled until you 
disable it. If you don't know whether or not it's enabled because its icon is hidden, you 
can use the following procedure to display the icon and make sure it's enabled. Any 
connections you make after enabling the SG Client are accelerated. 

To enable the SG Client using its system tray icon: 

1. Right-click the SG Client icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > [All] Programs > 
Blue Coat > SG Client > SG Client.) 

2. From the pop-up menu, click Enable SG Client. 

To enable the SG Client while you have the application open: 

1. Double-click the SG Client icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > [All] Programs > 
Blue Coat > SG Client > SG Client.) 

The SG Client dialog box displays. 

2. Click the Advanced tab. 

3. On the Advanced tab page, verify the value of Client Status. 

4. If Client Status is Disabled, click the General tab. 

5. On the General tab page, click Enable SG Client. 

Disabling the SG Client 

You can disable the SG Client in the event of network problems or if instructed to do so by 
your network administrator. 

To disable the SG Client using its system tray icon: 

1. Right-click the SG Client icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > [All] Programs > 
Blue Coat > SG Client > SG Client.) 

2. From the pop-up menu, click Disable SG Client. 

To disable the SG Client while you have the application open: 

1. Double-click the SG Client icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > [All] Programs > 
Blue Coat > SG Client > SG Client.) 

The SG Client dialog box displays. 

2. Click the General tab. 

3. On the General tab page, click Disable SG Client. 
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Troubleshooting the SG Client 

This section discusses suggested solutions to problems you might encounter with the SG 
Client. 

Suggested Solutions to Specific Problems 



Problem 



Solution 



Symptom: The SG Client download fails. 



Description: The SG Client installation fails and a dialog box similar to the 
following displays: 




Your network administrator of support personnel needs to determine 
the solution to this problem. To assist the administrator, send them all 
of the following log files: 

• Setup application log files, named sgclientsetup . log and 
sgclientsetup2 . log. 

These files are located in your Windows temporary folder, such as: 
C:\Documents and Settings\username\Local 
Settings\Temp 

• If it exists, the automatic update log file, named 
sgautoupdate . log 

This file is located in the SG Client installation folder, such as 
C:\Program Files\Blue Coat\SG Client. This file does not 
exist for new installations. 
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Problem 


Solution 


Symptom: An automatic update fails. 


Description: An SG Client update fails. 




Try to manually update the client, as follows: 

Double-click its icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > 
[All] Programs > Blue Coat > SG Client > SG Client.) 

In the SG Client dialog box, click the Advanced tab. 

On the Advanced tab page, click Check for Updates. 

If the Check for Updates button is unavailable, the SG Client might be 
disabled. To enable it, click the General tab and click Enable SG 
Client. 

If the manual update fails, send the following logs to your 
administrator. 

• Automatic update log, named sgautoupdate . log, located in the 
SG Client installation folder, such as C : \Program Files\Blue 
Coat\SG Client. 

• SG Client application log, as discussed in "Viewing and Saving 
the Log" on page 178. 



Symptom: You don't have enough available disk space. 




Description: The SG Client always leaves a minimum of 1GB on your system 
volume for your use. To free disk space, you can clear the SG Client cache at any time. 
Clearing the cache might slow performance when you're copying files but otherwise 
has no effect. 




Make sure the SG Client is enabled as discussed in "Enabling the SG 
Client" on page 174. 

Double-click its icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > 
[All] Programs > Blue Coat > SG Client > SG Client.) 

In the SG Client dialog box, click the General tab. 

On the General tab page, click Clear Cache. 
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Updating the SG Client Software and Configuration 

The SG Client should automatically check for software and / or configuration updates at 
the interval set by your administrator. However, you can check for updates anytime you 
want (for example, if network problems have prevented you from checking for updates 
earlier). 

To update the SG Client software and configuration: 

1. Enable the SG Client as discussed in "Enabling the SG Client" on page 174. 

2. Double-click the SG Client icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > [All] Programs > 
Blue Coat > SG Client > SG Client.) 

The SG Client dialog box displays. 

3. In the SG Client dialog box, click the Advanced tab. 

4. On the Advanced tab page, click Check for Updates. 

A dialog box displays to notify you of the result of the update. 

Note: If any software or configuration updates were applied, you must restart your 

machine — or disable and then enable the SG Client — for the updates to take effect. For 
more information, see "Enabling and Disabling the SG Client" on page 174. 

If errors display instead, see "Troubleshooting the SG Client" on page 175. 

Finding Information About The SG Client 

To assist support personnel, it might be necessary for you to find version information 
about SG Client components as discussed in this section. 

To find information about the SG Client software: 

1. Double-click the SG Client icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > [All] Programs > 
Blue Coat > SG Client > SG Client.) 

The SG Client dialog box displays. 

2. In the SG Client dialog box, click the About tab. 

The version of SG Client software you're running displays at the top of the About tab 
page. 

3. On the About tab page, do any of the following as instructed by your support 
personnel: 

• Click Copy to copy SG Client version information to the clipboard. You can then e- 
mail the information to your support personnel. 

• Click System Info to display information about your machine. 
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SG Client Logging 

The SG Client software maintains a diagnostic log that records the following: 

□ Client installation (that is, timestamp of the initial installation and any updates, 
including errors) 

□ Activation of the driver and client service components every time those components 
start 

□ Configuration download events (that is, whenever a configuration download is 
attempted and whether it succeed or failed) 

□ Connection information between the client machine and the ADN manager 

□ ADN tunnel creation and destruction 

□ Activation/ deactivation of the trace log, which is discussed in more detail in "Starting 
the Trace Log" on page 179. 

□ Various error conditions (for example, out of memory, out of disk space, and so on) 

Log entries include the date and time of each event. The log file is a maximum of 20MB in 
size, after which the oldest log entries are deleted as new entries are written. 

Viewing and Saving the Log 

This section discusses how to view the SG Client log file, copy it to the clipboard, or to 
save it in a different location. 

For information about the more detailed trace log, see "Starting the Trace Log" on page 
179. 

To view and save the SG Client log: 

1. Double-click the SG Client icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > [All] Programs > 
Blue Coat > SG Client > SG Client.) 

The SG Client dialog box displays. 

2. In the SG Client dialog box, click the Advanced tab. 

3. On the Advanced tab page, click View Log. 



The SG Client Log dialog box displays. 

4. You have the following options: 

Table 12-13. Viewing the SG Client Log 



To perform this task... 


... Use these steps 


To view the log 


Click View Log. The log file displays in a dialog box 
that enables you to read it, to copy it to the clipboard, or 
to save it. 


To copy the log to the clipboard 


Click View Log, then click Copy to Clipboard. 

Follow the directions from your network administrator 
or technical support to paste the log into an e-mail or an 
application like Notepad. 


To save the log 


Click View Log, then click Save Log. 

Follow the directions from your network administrator 
to e-mail the log. 
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5. In the SG Client Log dialog box, click OK. 

Starting the Trace Log 

The trace log contains more detailed information about your client session than does the 
client log. The trace log is not readable. 

To start the trace log: 

1. Double-click the SG Client icon in the system tray. 

(If the SG Client icon doesn't display in your system tray, click Start > [All] Programs > 
Blue Coat > SG Client > SG Client.) 

The SG Client dialog box displays. 

2. In the SG Client dialog box, click the Advanced tab. 

3. On the Advanced tab page, click Start Trace. 

A dialog box displays informing you the log was started. 

4. At the confirmation dialog box, click OK. 

5. Repeat the tasks that caused the problem for which you're seeking assistance. 

6. After a sufficient length of time has passed, or when instructed to do so by your 
network administrator or support personnel, click Stop Trace. 

A dialog box displays informing you the log was stopped. 

Note: Before sending it to anyone, you must stop the trace log. 

7. At the confirmation dialog box, click OK. 

8. Click Open Trace Folder. 

9. Locate the trace log, named sgdebug . etl, and e-mail it to your administrator or 
support. 

Uninstalling the SG Client Software 

To uninstall the SG Client software: 

1. Log in to your machine as a user who is a member of the Administrators group. 

If you are not in the Administrators group on your machine, contact your network 
administrator for alternate uninstallation methods. 

2. Click Start > Settings > Control Panel. 

3. In the Control Panel window, double-click Add or Remove Programs. 

4. Click Blue Coat SG Client. 

5. Click Remove. 

6. Follow the prompts on your screen to uninstall the software. 
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Troubleshooting Tips for Administrators 

For administrators to assist SG Client users with diagnosing errors, you need to be 
familiar with the topics discussed in this section: 

□ "SG Client Logging" on page 180 

□ "About Browser Proxies" on page 181 

□ "ADN Tunnels" on page 181 

□ "Clearing the Object Cache" on page 181 

□ "Client Manager Logging" on page 182 

SG Client Logging 



The SG Client maintains the following logs in the user's %TMP% folder: 
Table 12-14. SG Client Log Files 



File Name 


Description 


SGClientSetup . log 


SGClientSetup . exe log; displays errors related to 
downloading SGClientConf ig . xml or running 
SGClientSetup . exe. 


SGClientSetup2 . log 


SGClientSetup . msi log; displays errors related to 
installing the SG Client software. 



The SG Client maintains the following logs in the user's 
%windir%\system3 2 \sgclient\ support folder: 

Table 12-15. SG Client Log Files 



File Name 


Description 


sglog . etl 


SG Client application log. This file can reach a maximum of 
20MB in size, after which the oldest log entries are deleted as 
new entries are written. 


sgdebug . etl 


SG Client trace log. This file can reach a maximum of 20MB in 
size, after which the oldest log entries are deleted as new 
entries are written. 

This log is in a compiled format that is readable only by Blue 
Coat Engineering. 



The SG Client maintains the following log in the SG Client installation folder (for 
example, C : \Progr am Files\Blue Coat\SG Client): 

Table 12-16. SG Client Log Files 



File Name 


Description 


sgautoupdate . log 


Logs software updates but not configuration updates. 
Configuration update log messages are contained in 
sglog . etl. 
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About Browser Proxies 

For users to download SG Client software and configuration updates, you might need to 
change proxy settings for SSL traffic. If you don't use a proxy for SSL traffic, you can skip 
this section. 

The following options are available: 

□ If users can connect directly to the Client Manager, change the browser's proxy 
settings to exclude the Client Manager from being proxied. 

□ Change the proxy settings to allow connections to the Client Manager listen port (by 
default, 8084). You chose the Client Manager listen port as discussed in "Configuring 
the Client Manager" on page 156. 

This method works for all users — even those who cannot connect directly to the Client 
Manager. 



Note: The SG Client uses the Internet Explorer proxy settings to download software 

and configuration updates, so make sure you change Explorer's proxy settings. 



ADN Tunnels 

On the General tab page of the SG Client dialog box, clicking View ADN Tunnels displays 
detailed information about available tunnels, including whether a tunnel is idle or 
bypassed. 

An Idle tunnel is one that is not currently being used but for which connection 
information is preserved to decrease the amount of time required to use that connection 
later, if necessary. 

A Bypassed tunnel indicates an error with the connection to the indicated SG appliance. 

Clearing the Object Cache 

To free disk space on the user's system root volume, the user can clear the object cache by 
clicking Clear Cache on the SG Client dialog box's General tab page. The object cache is 
located in the user's %windir%\system32\sgclient\cif s folder, which is a hidden 
folder. 

Clearing the cache affects the performance of file copies, listing directories, and opening 
files in different applications. Also, clearing the cache while the client is running does not 
delete files that are currently in use. 
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Client Manager Logging 

The Client Manager logs success or failure events related to users downloading the SG 
Client software and configuration. Each log should include timestamp, HTTP GET string 
(including the HTTP return code), and client machine name). 

To get Client Manager logs: 

Enter the following URL in your browser's location field: 
https : / /host -.port / sgclient/log 

where host is the fully-qualified host name or IP address of the Client Manager, and 
port is the SG appliance's listen port. 



Licensing 

□ A new SG appliance has a 60-day trial license that permits you to use it with an 
unlimited number of clients. 

□ After the 60-day trial period, you are required to purchase a permanent license to 
continue using the SG Client. 

The license entitles you to support a certain number of clients in your enterprise; 
however, the license does not limit the number of ADN tunnels to which clients can 
have access. 

Client machines do not require a license to use the SG Client software; only the Client 
Manager appliance requires a license. 

□ You can upgrade your license to larger user counts. 

For information about applying a permanent Client Manager license, see the chapter on 
licensing in Volume 2: Getting Started. 
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The Blue Coat implementation of SOCKS includes the following: 

□ A SOCKS proxy server that supports both SOCKSv4/ 4a and SOCKSv5, running on 
the SG appliance. 

□ Support for forwarding through SOCKS gateways. 

To configure a SOCKS proxy server on the SG appliance, refer to Volume 3: Proxies and 
Proxy Services. To use SOCKS gateways when forwarding, continue with the next 
section. 



Note: SOCKS gateway aliases cannot be CPL keywords, such as no, default, forward, 
or socks_gateways. 



Using SOCKS Gateways 

SOCKS servers provide application level firewall protection for an enterprise. The 
SOCKS protocol provides generic way to proxy HTTP. 

SOCKS gateways, like ICP and forwarding, can use installable lists for configuration. 
You can configure the installable list using directives. You can also use the CLI to create 
a SOCKS gateways configuration. 

Using the CLI to Create SOCKS Gateways Settings 

If you prefer, you can use SOCKS gateways CLI commands instead of an installable list 
to create SOCKS gateways settings. For information about using an installable list, see 
"Using SOCKS Gateways Configuration Directives With Installable Lists" on page 186. 

To create a SOCKS gateways host: 

1. At the (config) command prompt: 

SGOS# (config) socks -gateways 

SGOS# (config socks -gateways) create gateway_alias gateway_host 
SOCKS_port [version {=4 | =5] [user=username password=password] 



Table 13-1. Commands to Create a SOCKS Gateways Host 



Command 


Suboptions 


Description 


gateway_alias 




A name, meaningful to you. 


gateway_host 




The IP address or the host name of the gateway where traffic is directed. 
The host name must DNS resolve. 


SOCKS_port 




The port number of the SOCKS gateway. 


version 


= 4 | =5 


The version that SOCKS gateways can support. (SOCKS v5 is 
recommended, if you have a choice). If no version is configured, the default 
is version 4. 
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Table 13-1 . Commands to Create a SOCKS Gateways Host (Continued) 



Command 


Suboptions 


Description 


user 


=username 


(Optional, and only if you use v5) The username of the user on the SOCKS 
gateway. The username already must exist on the gateway. If you use 
user=, you must also use passwords 


password 


=password 


(Optional, and only if you use v5) The password of the user on the SOCKS 
gateway. The password must match the gateway's information. If you use 
user=, you must also use passwords 



2. Repeat for each gateway you want to create. The failure-mode command applies to 
all SOCKS gateways configured on the system. The default failure mode can be 
overridden using policy. 



3. Complete the configuration by entering the following commands as necessary: 

SGOS# (config socks -gateways) failure-mode {open | closed} 

SGOS# (config socks -gateways) delete {all | gateway gateway_alias } 
SGOS# (config socks -gateways) path url 
SGOS# (config socks -gateways) no path 



Table 13-2. Commands to Complete SOCKS Gateways Configuration 



failure-mode 


open | closed 


If the health checks fail, open specifies that the connection be 
attempted without use of any SOCKS gateway (whether to an 
origin content server or a forwarding target); closed 
specifies that the connection be aborted. 


delete 


all | gateway 
gateway_alias 


Deletes all SOCKS gateways (delete all) or a specific 
SOCKS gateway (delete gateway gateway_al ias). 


path 


url 


(Optional) Specifies the download path to use if you 
download SOCKS-gateways settings through directives. 


no 


path 


Clears the network path URL to download SOCKS gateway 
settings. 



4. View the results. 

SGOS# (config socks -gateways) view 
SOCKS Gateways: (* = gateway unresolved) 

Sec_Appl 10.25.36.47 1080 V5 



Editing a SOCKS Gateways Host 

Once you have created a SOCKS gateways host, you can edit the settings. 



To edit the settings of a SOCKS gateways host: 



At the (config) command prompt: 



SGOS# (config) 
SGOS# (config 

SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 
SGOS# (config 



socks -gateways 

socks -gateways) edit gateway_alias 



socks -gateways 
socks -gateways 
socks -gateways 
socks -gateways 
socks -gateways 
socks -gateways 



gat eway_a lias) 
gateway_alias) 
gat eway_a lias) 
gateway_alias) 
gat eway_a lias) 
gat eway_a lias) 



host gateway_host 

no password | user 
password password 
port socks_port 
user username 
version 4 | 5 
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Table 13-3. Commands to Edit a SOCKS Gateways Host 



Commands 


Suboptions 


Description 


host 


gateway host 


Changes the host name. 


no 


password | user 


Optional, and only if you use version 5. Deletes the 
version 5 password or username. 


password 


password 


Optional, and only if you use version 5. Changes the 
version 5 password. 


port 


socks_port 


Changes the SOCKS port. 


user 


username 


Optional, and only if you use version 5. Changes the 
version 5 username. 


version 


4 | 5 


Changes the SOCKS version. 



Example 

SGOS# (config) socks-gateways 

SGOS# (config socks-gateways) edit testsocks 
SGOS# (config socks-gateways testsocks) port 23 
ok 

SGOS# (config socks-gateways testsocks) version 5 
ok 

SGOS# (config socks-gateways testsocks) exit 
SGOS# (config socks-gateways) exit 
SGOS# (config) 

Creating a Default Sequence 

A default sequence defines the order in which SOCKS gateways hosts are used. Only one 
default sequence is allowed. All members must be pre-existing hosts, and no member can 
be in the group more than once. 



Note: The default sequence (if present) is applied only if no applicable forwarding 
gesture is in policy. 



A default failover sequence allow healthy hosts to take over for an unhealthy host (one 
that is failing its DNS Resolution or its health check). The sequence specifies the order of 
failover, with the second host taking over for the first host, the third taking over for the 
second, and so on. 

If all hosts are unhealthy, the operation fails either open or closed, depending upon your 
settings. 

This configuration is usually created and managed through policy. If no SOCKS-gateways 
policy applies, you can create a default sequence through the CLI. This single default 
sequence consists of a single default host (or group) plus one or more hosts to use if the 
preceding ones are unhealthy. 

The syntax is 

sequence alias_name alias_name 

where alias_name is a space-separated list of one or more SOCKS gateways. 
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To create a default failover sequence, enter the following commands from the (config) 
prompt: 

SGOS# (config) socks-gateways 

SGOS# (config socks-gateways) sequence add gateway-alias 

SGOS# (config socks-gateways) sequence promote | demote gateway-alias 

SGOS# (config socks-gateways) sequence clear | remove gateway-alias 



Table 13-4. Commands to Create a Default Failover Sequence 



Command 


Suboptions 


Description 


sequence 


add 


Adds an alias to the end of the default fail-over sequence. 


clear 


Clears the default fail-over sequence. 


demote 


Demotes an alias one place towards the end of the default fail- 
over sequence. 


promote 


Promotes an alias one place towards the start of the default fail- 
over sequence. 


remove 


Removes an alias from the default fail-over sequence. 



Using SOCKS Gateways Configuration Directives With Installable Lists 

To configure a SOCKS gateway you must create an installable list and load it on the SG 
appliance. Alternately, you can use the CLI to configure SOCKS gateways. To use the CLI, 
see "Using the CLI to Create SOCKS Gateways Settings" on page 183. 

For information on installing the file itself, see "Creating a SOCKS Gateway Installable 
List" on page 188. 

The SOCKS gateways configuration includes SOCKS directives that: 

□ Names the SOCKS gateway hosts 

□ Specifies the SOCKS version 

□ (Optional, if using Version 5) Specifies user name and password 
Available directives are described in the table below. 

Table 13-5. SOCKS Gateway Directives 



Directive 


Meaning 


gateway 


Specifies the gateway alias and name, SOCKS port, version supported, 
usernames and password. 


socks_f ail 


In case connections cannot be made, specifies whether to abort the 
connection attempt or to connect to the origin content server 


sequence 


Specifies the order in which hosts should be used for failover. 



Syntax for the SOCKS directives are: 

gateway gateway_alias gateway_host SOCKS_port [version={4 | 5] 
[user= username password =password] 
socks_fail {open | closed} 
sequence gateway_name 
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Table 13-6. SOCKS Directives Syntax 



Command 


Suboptions 


Description 


gateway 




Configures the SOCKS gateway host. 




gateway alias 


A meaningful name that is used for policy rules. 




gateway name 


The IP address or host name of the gateway where traffic is directed. 
The host name must DNS resolve. 




SOCKS -port 


The port number of the SOCKS gateway. 




version={4 | 5} 


The version that SOCKS gateways can support. 




user = username 


(Optional, if you use v5) The username of the user on the SOCKS 
gateway. It already must exist on the gateway. 




password =password 


(Optional, if you use v5) The password of the user on the SOCKS 
gateway. It must match the gateway's information. 


socks_f ail 


{open | closed} 


If health checks fail, socks gateway .fail open specifies that the 
connection be attempted without using a SOCKS gateway (for 
example, go to the original server or forwarding target); 
socks gateway, fail closed specifies that the connection be 
aborted. The default is closed. Fail open is a security risk, and fail 
closed is the default if no setting is specified. This setting can be 
overridden by policy, (using the forward . fail open (yes | no) 
property). 


sequence 


gateway name 


Specifies the order in which hosts should be used for failover. 



Example 

gateway Sec_Appl 10.25.36.47 1022 version=5 user=u sername 
password =password 
socks_gateway . fail_open no 



Important: The username and password display in plaintext if you use the show 
config command. 



A default sequence defines the order in which forwarding hosts are used. Only one 
default sequence is allowed. All members must be pre-existing hosts and groups, and no 
member can be in the sequence more than once. 



Note: The default sequence (if present) is applied only if no applicable forwarding 
gesture is in policy. 



A default failover sequence works by allowing healthy hosts to take over for an unhealthy 
host (one that is failing its DNS Resolution or its health check). The sequence specifies the 
order of failover, with the second host taking over for the first host, the third taking over 
for the second, and so on). 

If all hosts are unhealthy, the operation fails either open or closed, depending upon your 
settings. 
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This configuration is generally created and managed through policy. If no SOCKS- 
gateways policy applies, you can create a default sequence through the CLI. This single 
default sequence consists of a single default host (or group) plus one or more hosts to use 
if the preceding ones are unhealthy. 

The syntax is 

sequence gateway_name gateway_name 

where gateway_name is a space-separated list of one or more SOCKS gateway aliases. 

Example 

sequence gateway_alias 

Creating a SOCKS Gateway Installable List 

You can create and install the SOCKS gateway installable list with the following methods: 

□ Use the Text Editor, which allows you to enter directives (or copy and paste the 
contents of an already-created file) directly onto the SG appliance. 

□ Create a local file on your local system; the SG appliance can browse to the file and 
install it. 

□ Use a remote URL, where you place an already-created file on an FTP or HTTP server 
to be downloaded to the SG appliance. 

When the SOCKS gateway installable list is created, it overwrites any previous SOCKS 
gateway configurations on the SG appliance. The installable list remains in effect until it is 
overwritten by another installable list; it can be modified or overwritten using CLI 
commands. 



Note: During the time that a forwarding installable list is being compiled and installed, 
forwarding is not available. Any transactions that come into the SG appliance during this 
time are not forwarded properly and are denied. 



Installation of SOCKS gateways installable-list configuration should be done outside peak 
traffic times. 

To create a SOCKS gateway installable list: 

1. Select Configuration > Forwarding > SOCKS Gateways. 

2. If you use a SOCKS gateway server for the primary or alternate forwarding gateway, 
you must specify the ID for the Identification (Ident) protocol used by the SOCKS 
gateway in SOCKS server handshakes. The default is bluecoat systems. 

3. From the drop-down list, select the method used to install the SOCKS gateway 
configuration; click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the configuration is 
located. To view the file before installing it, click View. Click Install. Examine the 
installation status that displays; click OK. 

• Local File: 



Click Browse to bring up the Local File Browse window. Browse for the file on the 
local system. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, click Close. 
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• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the installation is 
complete, a results window opens. View the results, close the window, click Close. 

4. Select Apply to commit the changes to the SG appliance. 

Related CLI Syntax to specify the SOCKS Gateway Machine ID 

SGOS# (config) socks -machine -id machine_ID 

Tip for SOCKS Configuration 

By default, SOCKS treats all incoming requests destined to port 80 as HTTP, allowing the 
usual HTTP policy to be performed on them, including ICAP scanning. If the SOCKS 
connection is being made to a server on another port, write policy on the SG appliance to 
match on the server host and port and specify that it is HTTP using SOCKS. 
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Use the TCP/IP configuration options to enhance the performance and security of the 
SG appliance. Except for IP Forwarding (refer to Volume 3: Proxies and Proxy Services), 
these commands are only available through the CLI. 

□ RFC-1323: Enabling RFC-1323 support enhances the high-bandwidth and long- 
delay operation of the SG appliances over very high-speed paths, ideal for satellite 
environments. 

□ TCP NewReno: Enabling TCP NewReno support improves the fast recovery of the 
appliances. 

□ ICMP Broadcast Echo: Disabling the response to these messages can limit security 
risks and prevent an attacker from creating a distributed denial of service (DDoS) to 
legitimate traffic. 

□ ICMP Timestamp Echo: Disabling the response to these messages can prevent an 
attacker from being able to reverse engineer some details of your network 
infrastructure. 

□ TCP Window Size: Configures the amount of unacknowledged TCP data that the 
SG appliance can receive before sending an acknowledgement. 

□ PMTU Discovery: Enabling PMTU Discovery prevents packets from being unable 
to reach their destination because they are too large. 

To view the TCP/IP configuration, see "Viewing the TCP/IP Configuration" on page 
194. 

This section discusses 

□ "RFC-1323" on page 191 

□ "TCP NewReno" on page 192 

□ "ICMP Broadcast Echo Support" on page 192 

□ "ICMP Timestamp Echo Support” on page 192 
a "TCP Window Size" on page 193 

a "PMTU Discovery" on page 193 

□ "TCP Time Wait" on page 193 

a "TCP Loss Recovery Mode" on page 194 
a "Viewing the TCP/IP Configuration" on page 194 



RFC-1323 

The RFC-1323 TCP/IP option enables the SG appliance to use a set of extensions to TCP 
designed to provide efficient operation over large bandwidth-delay-product paths and 
reliable operation over very high-speed paths, including satellite environments. RFC- 
1323 support can be configured through the CLI and is enabled by default. 
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To enable or disable RFC-1323 support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip rfc-1323 {enable | disable} 

TCP NewReno 

NewReno is a modification of the Reno algorithm. TCP NewReno improves TCP 
performance during fast retransmit and fast recovery when multiple packets are dropped 
from a single window of data. TCP NewReno support is enabled by default. 

To enable or disable TCP NewReno support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip tcp-newreno {enable | disable} 

ICMP Broadcast Echo Support 

Disabling the ICMP broadcast echo command can prevent the SG appliance from 
participating in a Smurf Attack. A Smurf attack is a type of Denial-of-Service (DoS) attack, 
where the attacker sends an ICMP echo request packet to an IP broadcast address. This is 
the same type of packet sent in the ping command, but the destination IP is broadcast 
instead of unicast. If all the hosts on the network send echo reply packets to the ICMP 
echo request packets that were sent to the broadcast address, the network is jammed with 
ICMP echo reply packets, making the network unusable. By disabling ICMP broadcast 
echo response, the SG appliance does not participate in the Smurf Attack. 

This setting is disabled by default. 

To enable or disable ICMP broadcast echo support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip icmp-bcast-echo {enable | disable} 

For more information on preventing DDoS attacks, see Chapter 3: "Attack Detection” on 
page 51. 

ICMP Timestamp Echo Support 

By disabling the ICMP timestamp echo commands, you can prevent an attacker from 
being able to reverse engineer some details of your network infrastructure. 

For example, disabling the ICMP timestamp echo commands prevents an attack that 
occurs when the SG appliance responds to an ICMP timestamp request by accurately 
determining the target's clock state, allowing an attacker to more effectively attack certain 
time-based pseudo-random number generators (PRNGs) and the authentication systems 
on which they rely. 

This setting is disabled by default. 

To enable or disable ICMP Timestamp echo support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip icmp-timestamp-echo {enable | disable} 
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TCP Window Size 

Adjusting the TCP window-size regulates the amount of unacknowledged data that the 
SG appliance receives before sending an acknowledgement. 

To configure the TCP window size: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip window-size window_size 

where window_size indicates the number of bytes allowed before acknowledgement 
(the value must be between 8192 and 4194304). 

PMTU Discovery 

PMTU (Path Maximum Transmission Unit) is a mechanism designed to discover the 
largest packet size sent that is not fragmented anywhere along the path between two 
communicating appliances that are not directly attached to the same link. 

An SG appliance that is not running PMTU might send packets larger than that allowed by 
the path, resulting in packet fragmentation at intermediate routers. Packet fragmentation 
affects performance and can cause packet discards in routers that are temporarily 
overtaxed. 

An SG appliance doing PMTU sets the Do -Not -Fragment bit in the IP header when 
transmitting packets. If fragmentation becomes necessary before the packets arrive at the 
second SG appliance, a router along the path discards the packets and returns an ICMP 
Host Unreachable error message, with the error condition of Needs -Fragmentation, to 
the original SG appliance. The first SG appliance then reduces the PMTU size and re- 
transmits the transmissions. 

The discovery period temporarily ends when the SG appliance estimates the PMTU is low 
enough that its packets can be delivered without fragmentation or when the SG appliance 
stops setting the Do -Not -Fragment bit. 

Following discovery and rediscovery, the size of the packets that are transferred between 
the two communicating nodes dynamically adjust to a size allowable by the path, which 
might contain multiple segments of various types of physical networks. 

PMTU is disabled by default. 

To configure PMTU discovery: 

At the (config) command prompt: 

SGOS# (config) tcp-ip pmtu-discovery enable | disable 



TCP Time Wait 

When a TCP connection is closed (such as when a user enters quit for an FTP session), the 
TCP connection remains in the TIME_WAIT state for twice the Maximum Segment 
Lifetime (MSL) before completely removing the connection control block. 

The TIME_WAIT state allows an end point (one end of the connection) to remove remnant 
packets from the old connection, eliminating the situation where packets from a previous 
connection are accepted as valid packets in a new connection. 

The MSL defines how long a packet can remain in transit in the network. The value of 
MSL is not standardized; the default value is assigned according to the specific 
implementation. 
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To change the MSL value, enter the following commands at the (config) command 
prompt: 

SGOS# (config) tcp-ip tcp-2msl seconds 

where seconds is the length of time you chose for the 2MSL value. Valid values are 1 

to 16380 inclusive. 

TCP Loss Recovery Mode 

A new TCP algorithm helps to recover throughput efficiently after packet losses occur and 
also addresses performance problems due to a single packet loss during a large transfer 
over long delay pipes. The feature is enhanced by default. 

To enable the algorithm: 

SGOS# (config) tcp-ip tcp-loss-recovery-mode {enhanced | aggressive} 

To disable the algorithm: 

SGOS# (config) tcp-ip tcp-loss-recovery-mode {normal} 

Viewing the TCP/IP Configuration 

To view the TCP/IP configuration: 

SGOS# (config) show tcp-ip 
RFC- 13 23 support: 

TCP Newreno support : 

IP forwarding: 

ICMP beast echo response : 

ICMP timestamp echo response 
Path MTU Discovery: 

TCP 2MSL timeout: 

TCP window size: 

TCP Loss Recovery Mode : 



enabled 
disabled 
disabled 
disabled 
: disabled 
disabled 
120 seconds 
65535 bytes 
Aggressive 
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Virtual IP (VIP) addresses are addresses assigned to a system (but not an interface) that 
are recognized by other systems on the network. Up to 255 VIPs can be configured on 
each SG appliance. They have several uses: 

□ Assign multiple identities to a system on the same or different network, partitioning 
the box in to separate logical entities for resource sharing or load sharing. 

□ Create an HTTPS Console to allow multiple, simultaneous, secure connections to 
the system. 

□ Direct authentication challenges to different realms. 

□ Set up failover among multiple SG appliances on the same subnet. 

Note: For information on creating an HTTPS Console, refer to Volume 3: Proxies and. 
Proxy Services; for information on using VIPs with authentication realms, refer to 
Volume 5: Securing the Blue Coat SG Appliance; to use VIPs with failover, see Chapter 6: 
"Configuring Failover" on page 87. 



To create a VIP: 

1. Select Configuration > Network > Advanced > VIPs. 

2. Click New. 

3. Enter the virtual IP address you want to use. It can be any IP address, except a 
multicast address. (A multicast address is a group address, not an individual IP 
address.) 



Note: You cannot create a VIP address that is the IP address used by the origin 
content server. You must assign a different address on the SG appliance, and use 
DNS or forwarding to point to the origin content server's real IP address. 



4. Click OK. 

5. Select Apply to commit the changes to the SG appliance. 
The VIP address can now be used. 



Related CLI Syntax to manage a VIP 

SGOS# (config) virtual address ip_address 
SGOS# (conf ig) virtual no address ip_address 
SGOS# (config) virtual clear 
SGOS# (config) show virtual 
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The SGOS software can be configured to participate in a WCCP (Web Cache Control 
Protocol) scheme, in which a WCCP-capable router collaborates with a set of WCCP- 
configured SG appliances to service requests. 



Note: Note: Bridge interfaces cannot be used in WCCP configurations. If the 

configuration includes bridge interfaces, you will receive the following error if you 
attempt to load the WCCP configuration file: 

Interface 0:0 is member of a bridge. 



Before you can install the WCCP configuration, you must create a WCCP configuration 
file for the SG appliance. The appliance does not ship with a default WCCP 
configuration file. 

You can install the WCCP settings in several ways: 

□ Text Editor, which allows you to enter settings (or copy and paste the contents of an 
already-created file) directly onto the appliance. 

□ Local file, installed on your system; the SG appliance can browse to the file and 
install it. 

□ A remote URL, where you place an already-created file on an LTP or HTTP server to 
be downloaded to the SG appliance. 

□ Using the CLI inline weep- settings command, which allows you to paste the 
WCCP settings into the CLI. 

□ Using the CLI weep command, which requires that you place an already-created file 
on an LTP or HTTP server and enter the URL into the CLI. 

Lor more information about WCCP, see Appendix C: "Using WCCP" on page 211. 

To install WCCP settings: 

1. Select Configuration > Network > Advanced > WCCP. 

2. Prom the drop-down list, select the method used to install the WCCP settings; click 

Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the WCCP file is 
located. To view the file before installing it, click View. Click Install. View the 
installation status that displays; click OK. 

• Local Pile: 

Click Browse to display the Local Pile Browse window. Browse for the file on 
the local system. Open it and click Install. When the installation is complete, a 
results window opens. View the results, close the window, and click Close. 
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• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the installation is 
complete, a results window opens. View the results, close the window, and click 

Close. 

3. Select Apply to commit the changes to the SG appliance. 

Related CLI Syntax to Install WCCP Settings 

□ To enter WCCP settings directly onto the SG appliance, enter the following commands 
at the (config) command prompt: 

SGOS# (config) inline wccp-settings end- of - f ile_marker 

weep enable 

weep version 2 

service-group 9 

priority 1 

protocol 6 

service -flags destination- ip -hash 
service-flags ports-def ined 
ports 80 21 1755 554 80 80 80 80 
interface 6 

home-router 10.16.18.2 
forwarding 12 
eof 

□ To enter a path to a remote URL where you have placed an already-created static route 
table, enter the following commands at the # (config) command prompt: 

SGOS# (config) weep path url 

where url is a fully qualified URL, including the filename, where the configuration 
file is located. 

SGOS# (config) load wccp-settings 

SGOS# (config) weep enable 
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Term 


Description 


ADN Optimize Attribute 


Controls whether to optimize bandwidth usage when connecting upstream using an 
ADN tunnel. 


Asynchronous Adaptive 
Refresh (AAR) 


This allows the ProxySG to keep cached objects as fresh as possible, thus reducing 
response times. The AAR algorithm allows HTTP proxy to manage cached objects 
based on their rate of change and popularity: an object that changes frequently and/ 
or is requested frequently is more eligible for asynchronous refresh compared to an 
object with a lower rate of change and/ or popularity. 


Asynchronous Refresh 
Activity 


Refresh activity that does not wait for a request to occur, but that occurs 
asynchronously from the request. 


Attributes (Service) 


The service attributes define the parameters, such as explicit or transparent, 
cipher suite, and certificate verification, that the SC appliance uses for a 
particular service. . 


Authenticate-401 Attribute 


All transparent and explicit requests received on the port always use transparent 
authentication (cookie or IP, depending on the configuration). This is especially 
useful to force transparent proxy authentication in some proxy-chaining scenarios 


authentication 


The process of identifying a specific user. 


authorization 


The permissions given to a specific user. 


Bandwidth Gain 


A measure of the difference in client-side and server-side Internet traffic expressed in 
relation to server-side Internet traffic. It is managed in two ways: you can enable or 
disable bandwidth gain mode or you can select the Bandwidth Gain profile (this also 
enables bandwidth gain mode).. 


Bandwidth Class 


A defined unit of bandwidth allocation. An administrator uses bandwidth classes to 
allocate bandwidth to a particular type of traffic flowing through the SC appliance. 


Bandwidth Class Hierarchy 


Bandwidth classes can be grouped together in a class hierarchy, which is a tree 
structure that specifies the relationship among different classes. You create a 
hierarchy by creating at least one parent class and assigning other classes to be its 
children. 


Bandwidth Policy 


The set of rules that you define in the policy layer to identify and classify the traffic in 
the SC appliance, using the bandwidth classes that you create. You must use policy 
(through either VPM or CPL) in order to manage bandwidth. 


Bypass Lists 


The bypass list allows you to exempt IP addresses from being proxied by the SC 
appliance. The bypass list allows either <A11> or a specific IP prefix entry for 
both the client and server columns. Both UDP and TCP traffic is 
automatically exempted. 
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Term 


Description 


Byte-Range Support 


The ability of the ProxySG to respond to byte-range requests (requests with a Range : 
HTTP header). 


Cache-hit 


An object that is in the ProxySG and can be retrieved when an end user requests the 
information. 


Cache-miss 


An object that can be stored but has never been requested before; it was not in the 
ProxySG to start, so it must be brought in and stored there as a side effect of 
processing the end-user's request. If the object is cacheable, it is stored and served the 
next time it is requested. 


Child Class (Bandwidth 
Gain) 


The child of a parent class is dependent upon that parent class for available 
bandwidth (they share the bandwidth in proportion to their minimum /maximum 
bandwidth values and priority levels). A child class with siblings (classes with the 
same parent class) shares bandwidth with those siblings in the same manner. 


Client consent certificates 


A certificate that indicates acceptance or denial of consent to decrypt an end user's 
HTTPS request. 


Compression 


An algorithm that reduces a file's size but does not lose any data. The ability to 
compress or decompress objects in the cache is based on policies you create. 
Compression can have a huge performance benefit, and it can be customized based 
on the needs of your environment: Whether CPU is more expensive (the default 
assumption), server-side bandwidth is more expensive, or whether client-side 
bandwidth is more expensive. 


Default Proxy Listener 


See " Proxy Service (Default)" . 


Detect Protocol Attribute 


Detects the protocol being used. Protocols that can be detected include: 

HTTP, P2P (eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper. 


Directives 


Directives are commands that can be used in installable lists to configure forwarding. 
See also forwarding Configuration. 


Display Filter 


The display filter is a drop-down list at the top of the Proxy Services pane that allows 
you to view the created proxy services by service name or action. 


Early Intercept Attribute 


Controls whether the proxy responds to client TCP connection requests before 
connecting to the upstream server. When early intercept is disabled, the proxy delays 
responding to the client until after it has attempted to contact the server. 


Emulated Certificates 


Certificates that are presented to the user by ProxySG when intercepting 
HTTPS requests. Blue Coat emulates the certificate from the server and signs 
it, copying the subjectName and expiration. The original certificate is used 
between the ProxySG and the server. 


ELFF-compatible format 


A log type defined by the W3C that is general enough to be used with any protocol. 


Encrypted Log 


A log is encrypted using an external certificate associated with a private key. 
Encrypted logs can only be decrypted by someone with access to the private key. The 
private key is not accessible to the SC appliance. 
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Term 


Description 


explicit proxy 


A configuration in which the browser is explicitly configured to communicate with 
the proxy server for access to content. 

This is the default for the SG appliance, and requires configuration for both browser 
and the interface card. 


Fail Open/Closed 


Failing open or closed applies to forwarding hosts and groups and SOCKS gateways. 
Fail Open/ Closed applies when the health checks are showing sick for each 
forwarding or SOCKS gateway target in the applicable fail-over sequence. If no 
systems are healthy, the SG appliance fails open or closed, depending on the 
configuration. If closed, the connection attempt simply fails. 

If open, an attempt is made to connect without using any forwarding target (or 
SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no 
setting is specified. 


Forwarding Configuration 


Forwarding can be configured through the CLI or through adding directives to a text 
file and installing it as an installable list. Each of these methods (the CLI or using 
directives) is equal. You cannot use the Management Console to configure 
forwarding. 


Forwarding Host 


Upstream Web servers or proxies. 


forward proxy 


A proxy server deployed close to the clients and used to access many servers. A 
forward proxy can be explicit or transparent. 


Freshness 


A percentage that reflects the objects in the ProxySG cache that are expected to be 
fresh; that is, the content of those objects is expected to be identical to that on the OCS 
(origin content server). 


Gateway 


A device that serves as entrance and exit into a communications network. 


Global Default Settings 


You can configure settings for all forwarding hosts and groups. These are called the 
global defaults. You can also configure private settings for each individual 
forwarding host or group. Individual settings override the global defaults. 


FTP 


See Native FTP; Web FTP. 


Host Affinity 


Host affinity is the attempt to direct multiple connections by a single user to the same 
group member. Host affinity is closely tied to load balancing behavior; both should 
configured if load balancing is important. 


Host Affinity Timeout 


The host affinity timeout determines how long a user remains idle before the 
connection is closed. The timeout value checks the user's IP address, SSL ID, or 
cookie in the host affinity table. 


Inbound Traffic (Bandwidth 
Gain) 


Network packets flowing into the SG appliance. Inbound traffic mainly consists of 
the following: 

• Server inbound: Packets originating at the origin content server (OCS) and sent to 
the SG appliance to load a Web object. 

• Client inbound: Packets originating at the client and sent to the SG 
appliance for Web requests. 
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Term 


Description 


Installable Lists 


Installable lists, comprised of directives, can be placed onto the SG appliance in one 
of several methods: through creating the list through the SG text editor, by placing 
the list at an accessible URL, or by downloading the directives file from the local 
system. 


Integrated Host Timeout 


An integrated host is an Origin Content Server (OCS) that has been added to the 
health check list. The host, added through the integrate new hosts property, 
ages out of the integrated host table after being idle for the specified time. The default 
is 60 minutes. 


IP Reflection 


Determines how the client IP address is presented to the origin server for explicitly 
proxied requests. All proxy services contain a reflect-ip attribute, which enables or 
disables sending of client's IP address instead of the SG's IP address. 


Issuer keyring 


The keyring that is used by the SG appliance to sign emulated certificates. The 
keyring is configured on the appliance and managed through policy. 


Listener 


The service that is listening on a specific port. A listener can be identified by any 
destination IP / subnet and port range. Multiple listeners can be added to 
each service. 


Load Balancing 


The ability to share traffic requests among multiple upstream targets. Two methods 
can be used to balance the load among systems: least -connect ions or round - 
robin . 


Log Facility 


A separate log that contains a single logical file and supports a single log format. It 
also contains the file's configuration and upload schedule information as well as 
other configurable information such as how often to rotate (switch to a new log) the 
logs at the destination, any passwords needed, and the point at which the facility can 
be uploaded. 


Log Format 


The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or 
Websense. 

The proprietary log types each have a corresponding pre-defined log format that has 
been set up to produce exactly that type of log (these logs cannot be edited). In 
addition, a number of other ELFF type log formats are also pre-defined (im, main, 
p2p, ssl, streaming). These can be edited, but they start out with a useful set of log 
fields for logging particular protocols understood by the SG appliance. It is also 
possible to create new log formats of type ELFF or Custom which can contain any 
desired combination of log fields. 


Log Tail: 


The access log tail shows the log entries as they get logged. With high traffic on the 
SG appliance, not all access log entries are necessarily displayed. However, you can 
view all access log information after uploading the log. 


Maximum Object Size 


The maximum object size stored in the ProxySG. All objects retrieved that are greater 
than the maximum size are delivered to the client but are not stored in the ProxySG. 


NCSA common log format 


A log type that contains only basic HTTP access information. 
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Term 


Description 


Negative Responses 


An error response received from the OCS when a page or image is requested. If the 
ProxySG is configured to cache such negative responses, it returns that response in 
subsequent requests for that page or image for the specified number of minutes. If it 
is not configured, which is the default, the ProxySG attempts to retrieve the page or 
image every time it is requested. 


Native FTP 


Native FTP involves the client connecting (either explicitly or transparently) using 
the FTP protocol; the SC appliance then connects upstream through FTP (if 
necessary). 


Outbound Traffic 
(Bandwidth Gain) 


Network packets flowing out of the SC appliance. Outbound traffic mainly consists 
of the following: 

• Client outbound: Packets sent to the client in response to a Web request. 

• Server outbound: Packets sent to an OCS or upstream proxy to request a service. 


Origin Content Server (OCS) 




Parent Class (Bandwidth 
Gain) 


A class with at least one child. The parent class must share its bandwidth with its 
child classes in proportion to the minimum/ maximum bandwidth values or priority 
levels. 


PASV 


Passive Mode Data Connections. Data connections initiated by an FTP client to 
an FTP server. 


proxy 


Caches content, filters traffic, monitors Internet and intranet resource usage, blocks 
specific Internet and intranet resources for individuals or groups, and enhances the 
quality of Internet or intranet user experiences. 

A proxy can also serve as an intermediary between a Web client and a Web server 
and can require authentication to allow identity based policy and logging for the 
client. 

The rules used to authenticate a client are based on the policies you create on the SG 
appliance, which can reference an existing security infrastructure — LDAP, RADIUS, 
IWA, and the like. 


Proxy Service 


The proxy service defines the ports, as well as other attributes, that are used by the 
proxies associated with the service. 


Proxy Service (Default) 


The default proxy service is a service that intercepts all traffic not otherwise 
intercepted by other listeners. It only has one listener whose action can be set to 
bypass or intercept. No new listeners can be added to the default proxy service, and 
the default listener and service cannot be deleted. Service attributes can be changed. 


realms 


A realm is a named collection of information about users and groups. The name is 
referenced in policy to control authentication and authorization of users for access to 
Blue Coat Systems SG services. Multiple authentication realms can be used on a 
single SG appliance. Realm services include IWA, LDAP, Local, and RADIUS. 


Reflect Client IP Attribute 


Enables the sending of the client's IP address instead of the SG's IP address to the 
upstream server. If you are using an Application Delivery Network (ADN), this 
setting is enforced on the concentrator proxy through the Configuration>App. 
Delivery Network>Tunneling tab. 
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Term 


Description 


Refresh Bandwidth 


The amount of bandwidth used to keep stored objects fresh. By default, the ProxySG 
is set to manage refresh bandwidth automatically. You can configure refresh 
bandwidth yourself, although Blue Coat does not recommend this. 


reverse proxy 


A proxy that acts as a front-end to a small number of pre-defined servers, typically to 
improve performance. Many clients can use it to access the small number of 
predefined servers. 


rotate logs 


When you rotate a log, the old log is no longer appended to the existing log, and a 
new log is created. All the facility information (headers for passwords, access log 
type, and so forth), is re-sent at the beginning of the new upload. 

If you're using Reporter (or anything that doesn't understand the concept of "file," 
such as streaming) the upload connection is broken and then re-started, and, again, 
the headers are re-sent. 


serial console 


A device that allows you to connect to the SG appliance when it is otherwise 
unreachable, without using the network. It can be used to administer the SG 
appliance through the CLI. You must use the CLI to use a serial console. 
Anyone with access to the serial console can change the administrative access 
controls, so physical security of the serial console is critical. 


Server Certificate Categories 


The hostname in a server certificate can be categorized by BCWF or another content 
filtering vendor to fit into categories such as banking, finance, sports. 


Sibling Class (Bandwidth 
Gain) 


A bandwidth class with the same parent class as another class. 


SOCKS Proxy 


A generic way to proxy TCP and UDP protocols. The SG appliance supports both 
SOCKSv4/4a and SOCKSv5; however, because of increased username and password 
authentication capabilities and compression support. Blue Coat recommends that 
you use SOCKS v5.. 


SmartReporter log type 


A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter 
tool. 


Split proxy 


Employs co-operative processing at the branch and the core to implement 
functionality that is not possible in a standalone proxy. Examples of split 
proxies include : 

Mapi Proxy 
SSL Proxy 


SQUID-compatible format 


A log type that was designed for cache statistics. 


SSL 


A standard protocol for secure communication over the network. Blue Coat 
recommends using this protocol to protect sensitive information. 


SSL Interception 


Decrypting SSL connections. 


SSL Proxy 


A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or 
reverse proxy mode. 
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Term 


Description 


static routes 


A manually-configured route that specifies the transmission path a packet must 
follow, based on the packet's destination address. A static route specifies a 
transmission path to another network. 


SurfControl log type 


A proprietary log type that is compatible with the SurfControl reporter tool. The 
SurfControl log format includes fully-qualified usernames when an NTLM realm 
provides authentication. The simple name is used for all other realm types. 


Traffic Flow (Bandwidth 
Gain) 


Also referred to as flow. A set of packets belonging to the same TCP/UDP connection 
that terminate at, originate at, or flow through the SG appliance. A single request 
from a client involves two separate connections. One of them is from the client to the 
SG appliance, and the other is from the SG appliance to the OCS. Within each of 
these connections, traffic flows in two directions — in one direction, packets flow out 
of the SG appliance (outbound traffic), and in the other direction, packets flow into 
the SG (inbound traffic). Connections can come from the client or the server. Thus, 
traffic can be classified into one of four types: 

• Server inbound 

• Server outbound 

• Client inbound 

• Client outbound 

These four traffic flows represent each of the four combinations described above. 
Each flow represents a single direction from a single connection. 


transparent proxy 


A configuration in which traffic is redirected to the SG appliance without the 
knowledge of the client browser. No configuration is required on the browser, but 
network configuration, such as an L4 switch or a WCCP-compliant router, is 
required. 


Variants 


Objects that are stored in the cache in various forms: the original form, fetched from 
the OCS; the transformed (compressed or uncompressed) form (if compression is 
used). If a required compression variant is not available, then one might be created 
upon a cache-hit. (Note: policy-based content transformations are not stored in the 
ProxySG.) 


Web FTP 


Web FTP is used when a client connects in explicit mode using HTTP and 
accesses an ftp:/ / URL. The SG appliance translates the HTTP request into 
an FTP request for the OCS (if the content is not already cached), and then 
translates the FTP response with the file contents into an HTTP response for 
the client. 


Websense log type 


A proprietary log type that is compatible with the Websense reporter tool. 
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Term 


Description 


Wildcard Services 


When multiple non-wildcard services are created on a port, all of them must be of the 
same service type (a wildcard service is one that is listening for that port on all IP 
addresses). If you have multiple IP addresses and you specify IP addresses for a port 
service, you cannot specify a different protocol if you define the same port on another 
IP address. For example, if you define HTTP port 80 on one IP address, you can only 
use the HTTP protocol on port 80 for other IP addresses. 

Also note that wildcard services and non-wildcard services cannot both exist at the 
same time on a given port. 

For all service types except HTTPS, a specific listener cannot be posted on a port if 
the same port has a wildcard listener of any service type already present. 
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After ICP, forwarding, and the SOCKS gateways are configured, use policy to create 
and manage forwarding rules. Forwarding, ICP, and SOCKS gateway rules should go 
in the <Forward> layer of the Forwarding Policy file or the VPM Policy file (if you use 
the VPM). 

The separate <Forward> layer is provided because the URL can undergo URL rewrites 
before the request is fetched. This rewritten URL is accessed as a server _ur l and 
decisions about upstream connections are based on the rewritten URL, requiring a 
separate layer. All policy commands allowed in the <Forward> layer are described 
below. 



Table B-1 . Policy Commands Allowed in the <Forward> Layer 



Forwarding 


Description 


Conditions 


client address= 


Tests the IP address of the client. Can also be used in 
<Exception> and < Proxy > layers. 


client . host= 


Tests the hostname of the client (obtained through RDNS). Can 
also be used in <Admin>, <Proxy>, and <Exception> layers. 


client . host . has name= 


Tests the status of the RDNS performed to determine 
client . host. Can also be used in <Admin>, <Proxy>, and 
<Exception> layers. 


client .protocol= 


Tests true if the client transport protocol matches the 
specification. Can also be used in <Exception> and <Proxy> 
layers. 


date [ .utc] = 


Tests true if the current time is within the startdate..enddate 
range, inclusive. Can be used in all layers. 


day= 


Tests if the day of the month is in the specified range or an exact 
match. Can be used in all layers. 


has client= 


has client= is used to test whether or not the current 
transaction has a client. This can be used to guard triggers that 
depend on client identity. 


hour [ .utc] = 


Tests if the time of day is in the specified range or an exact match. 
Can be used in all layers. 


im. client= 


Tests the type of IM client in use. Can also be used in < Proxy >, 
<Exception>, and <Cache> layers. 


im. message . ref lected= 


Tests whether IM reflection occurred. Can also be used in 
<Proxy> and <Cache> layers. 


minute [ .utc] =month [ .utc] = 


Tests if the minute of the hour is in the specified range or an exact 
match. Can be used in all layers. 
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Table B-1. Policy Commands Allowed in the <Forward> Layer (Continued) 



Forwarding 


Description 


proxy . address= 


Tests the IP address of the network interface card (NIC) on which 
the request arrives. Can also be used in <Admin> and <Proxy> 
layers. 


proxy. card= 


Tests the ordinal number of the network interface card (NIC) 
used by a request. Can also be used in <Admin> and <Proxy> 
layers. 


proxy. port= 


Tests if the IP port used by a request is within the specified range 
or an exact match. Can also be used in <Admin> and < Proxy > 
layers. 


server url [.case sensitive | . no 
lookup] = 


Tests if a portion of the requested URL exactly matches the 
specified pattern. 


server url.address= 


Tests if the host IP address of the requested URL matches the 
specified IP address, IP subnet, or subnet definition. 


server url . domain [. case sensitive] 
[ . no_lookup] = 


Tests if the requested URL, including the domain-suffix portion, 
matches the specified pattern. 


server url . extension [. case 
sensitive] = 


Tests if the filename extension at the end of the path matches the 
specified string. 


server url. host. has name= 


Tests whether the server URL has a resolved DNS hostname. 


server url . host [ . exact | . substring | 
.prefix| ,suffix| .regex] [.no lookup 
] = 


Tests if the host component of the requested URL matches the IP 
address or domain name. 


server url. host. is numeric= 


This is true if the URL host was specified as an IP address. 


server url.host.no name= 


This is true if no domain name can be found for the URL host. 


server url . host . regex= 


Tests if the specified regular expression matches a substring of 
the domain name component of the requested URL. 


server url. is absolute= 


Tests whether the server URL is expressed in absolute form. 


server url . path [. exact | . substring! 
.prefix| • suffix | .regex] 

[ . case_sensitive] = 


Tests if a prefix of the complete path component of the requested 
URL, as well as any query component, matches the specified 
string. 


server url . path . regex= 


Tests if the regex matches a substring of the path component of 
the request URL. 


server url.port= 


Tests if the port number of the requested URL is within the 
specified range or an exact match. 


server url . query . regex= 


Tests if the regex matches a substring of the query string 
component of the request URL. 


server url . regex= 


Tests if the requested URL matches the specified pattern. 


server url . scheme= 


Tests if the scheme of the requested URL matches the specified 
string. 


socks= 


This condition is true whenever the session for the current 
transaction involves SOCKS to the client. 
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Table B-1. Policy Commands Allowed in the <Forward> Layer (Continued) 



Forwarding 


Description 


socks . version^ 


Switches between SOCKS 4/4a and 5. Can also be used in 
<Exception> and <Proxy> layers. 


streaming . client= 


yes | no. Tests the user agent of a Windows, Real Media, or 
QuickTime player. 


time [ .utc] = 


Tests if the time of day is in the specified range or an exact match. 
Can be used in all layers. 


tunneled= 


yes | no. Tests TCP tunneled requests, HTTP CONNECT 
requests, and unaccelerated SOCKS requests 


weekday [ . utc] = 


Tests if the day of the week is in the specified range or an exact 
match. Can be used in all layers. 


year [ .utc] = 


Tests if the year is in the specified range or an exact match. Can 
be used in all layers. 


Properties 


access_server ( ) 


Determines whether the client can receive streaming content 
directly from the OCS. Set to no to serve only cached content. 


ftp . transport ( ) 


Determines the upstream transport mechanism. 

This setting is not definitive. It depends on the capabilities of the 
selected forwarding host. 


forward ( ) 


Determines forwarding behavior. 

There is a box-wide configuration setting 
(conf ig>f orwarding>f ailure-mode) for the forward 
failure mode. The optional specific settings can be used to 
override the default. 


forward. fail open() 


Controls whether the SG appliance terminates or continues to 
process the request if the specified forwarding host or any 
designated backup or default cannot be contacted. 


http . refresh . recv . timeout ( ) 


Sets the socket timeout for receiving bytes from the upstream 
host when performing refreshes. Can also be used in < Cache > 
layers. 


http . server . connect attempts!) 


Sets the number of attempts to connect performed per-address 
when connecting to the upstream host. 


http . server . recv . timeout ( ) 


Sets the socket timeout for receiving bytes from the upstream 
host. Can also be used in <Proxy> layers. 


icp ( ) 


Determines when to consult ICP. The default is yes if ICP hosts 
are configured and if no forwarding host or SOCKS gateway is 
identified as an upstream target. 


im. transport ( ) 


Sets the type of upstream connection to make for IM traffic. 


integrate_new_hosts ( ) 


Determines whether to add new host addresses to health checks 
and load balancing. The default is no. If it is set to yes, any new 
host addresses encountered during DNS resolution of 
forwarding hosts are added to health checks and load balancing. 
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Table B-1. Policy Commands Allowed in the <Forward> Layer (Continued) 



Forwarding 


Description 


ref lect_ip ( ) 


Determines how the client IP address is presented to the origin 
server for explicitly proxied requests. Can also be used in 
< Proxy > layers. 


socks_gateway ( ) 


The socks gateway ( ) property determines the gateway and 
the behavior of the request if the gateway cannot be contacted. 
There is a box-wide configuration setting for the SOCKS failure 
mode. The optional specific settings can be used to override the 
default. 


socks_gateway . f ail_open ( ) 


Controls whether the SG appliance terminates or continues to 
process the request if the specified SOCKS gateway or any 
designated backup or default cannot be contacted. 


streaming . transport ( ) 


Determines the upstream transport mechanism. This setting is 
not definitive. The ability to use streaming . transport ( ) 
depends on the capabilities of the selected forwarding host. 


trace . request ( ) 


Determines whether detailed trace output is generated for the 
current request. The default value is no, which produces no 
output 


trace . rules ( ) 


Determines whether trace output is generated that shows each 
policy rule that fired. The default value of no suppresses output. 


trace . destination ( ) 


Used to change the default path to the trace output file. By 
default, policy evaluation trace output is written to an object in 
the cache accessible using a console URL of the following form: 

http : //ProxySG ip address : 8081 /Policy/ 
Trace/path 


Actions 




notify email () 


Sends an e-mail notification to the list of recipients specified in 
the Event Log mail configuration. Can be used in all layers. 


notify_snmp ( ) 


The SNMP trap is sent when the transaction terminates. Can be 
used in all layers. 


log_message 


Writes the specified string to the event log. 


Definitions 




define server url. domain condition 
name 


Binds a user-defined label to a set of domain suffix patterns for 
use in a condition= expression. 
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This appendix discusses how to configure an SG appliance to participate in a Web Cache 
Communication Protocol (WCCP) scheme, when a WCCP-capable router collaborates 
with a set of WCCP-configured appliances to service requests. If you are already 
familiar with WCCP version 2 and want to get your router and SG appliance up and 
running right away, see the "Quick Start" on page 213. 



Overview 

WCCP is a Cisco®-developed protocol that allows you to establish redirection of the 
traffic that flows through routers. 

The main benefits of using WCCP are: 

□ Scalability. With no reconfiguration overhead, redirected traffic can be 
automatically distributed to up to 32 appliances. 

□ Redirection safeguards. If no appliances are available, redirection stops and the 
router forwards traffic to the original destination address. 

WCCP has two versions, version 1 and version 2, both of which are supported by Blue 
Coat. However, only one protocol version can be active on the SG appliance at a time. 
The active WCCP protocol set up in the SG configuration must match the version 
running on the WCCP router. 

Using WCCP and Transparent Redirection 

A WCCP-capable router operates in conjunction with the appliances to transparently 
redirect traffic to a set of caches that participate in the specified WCCP protocol. IP 
packets are redirected based on fields within each packet. For instance, WCCP version 
1 only redirects destination TCP port 80 (default HTTP traffic) IP packets. WCCP 
version 2 allows you to redirect traffic from other ports and protocols. 

Load balancing is achieved through a redirection hash table to determine which SG 
appliance receives the redirected packet. 

WCCP Version 1 

In WCCP version 1, the WCCP-configured home router transparently redirects TCP 
port 80 packets to a maximum of 32 appliances. (An SG appliance is seen as a cache in 
WCCP protocol.) 

One of the caches participating in the WCCP service group is automatically elected to 
configure the home router's redirection tables. This way, caches can be transparently 
added and removed from the WCCP service group without requiring operator 
intervention. WCCP version 1 supports only a single service group. 

Each applicable client IP packet received by the home router is transparently redirected 
to a cache. An SG appliance from the group is selected to define the home router's 
redirection hash table for all caches. All caches periodically communicate with the 
home router to verify WCCP protocol synchronization and SG availability within the 
service group. In return, the home router responds to each cache with information as to 
which appliances are available in the service group. 
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The following are WCCP version 1 caveats: 

□ The home router IP must be configured on all participating interfaces and must match 
the home router address configured on the SG appliance. 

□ The adapter connected to the SG appliance must be Ethernet or Fast Ethernet. 

□ For Cisco routers using WCCP version 1, minimum IOS releases are 11.1(18)CA and 
11.2(13)P. Note that releases prior to IOS 12.0(3)T only support WCCP version 1. 
Ensure that you are using the correct IOS software for the router and that the SG 
configuration protocol version number and router protocol version number match. 

For more information on WCCP Version 1, refer to the Cisco Web site. The rest of this 
appendix discusses WCCP version 2 only. 

WCCP Version 2 

For Cisco routers using WCCP version 2, minimum IOS releases are 12.0(3)T and 12.0(4). 
Release 12.0(5) and later releases support WCCP versions 1 and 2. Ensure that you use the 
correct IOS software for the router and that you have a match between the SG 
configuration WCCP version number and router protocol version number. 

WCCP version 2 protocol offers the same capabilities as version 1, along with increased 
protocol security and multicast protocol broadcasts. Version 2 multicasting allows caches 
and routers to discover each other through a common multicast service group and 
matching passwords. In addition, up to 32 WCCP-capable routers can transparently 
redirect traffic to a set of up to 32 appliances. Version 2 WCCP-capable routers are capable 
of redirecting IP traffic to a set of appliances based on various fields within those packets. 

Version 2 allows routers and caches to participate in multiple, simultaneous service 
groups. Routers can transparently redirect IP packets based on their formats. For example, 
one service group could redirect HTTP traffic and another could redirect FTP traffic. 



Note: Blue Coat recommends that WCCP-compliant caches from different vendors be 
kept separate and that only one vendor's routers be used in a service group. 



One of the caches participating in the WCCP service group is automatically elected to 
configure the home router's redirection tables. This way, caches can be transparently 
added and removed from the WCCP service group without requiring operator 
intervention. WCCP version 2 supports multiple service groups. 
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The figure below illustrates a WCCP version 2 implementation using multiple routers and 
Appliances. In this scenario, routers 1 through n and caches 1 through m participate in the 
same service group. As in version 1, an appliance from the group is selected to define the 
redirection hash table in all routers for all caches. All caches periodically communicate 
with all routers to verify WCCP protocol synchronization and appliance and router 
availability within the service group. In return, each router responds to caches with 
information as to what caches and discovered routers are available in the service group. 




Figure C-2. A Version 2 Configuration Using Packet Redirection to Multiple Routers and Caches 



Quick Start 

Two tasks must be completed to get WCCP running: configuring the router and 
configuring the SG appliance. If you have a standard router and SG configuration, use the 
Quick Start below. Otherwise, begin with the instructions in the procedure "To do initial 
router configuration:”, below, and "To create an SG appliance WCCP configuration file 
and enable WCCP:" on page 214. 

If you require a more complicated configuration, start with "Creating an SG Appliance 
WCCP Configuration File" on page 220. 

To do initial router configuration: 

1. From the router (conf ig) mode, tell WCCP which service group you want use. The 
Web-cache service group redirects port 80 (HTTP) traffic only. 

Router (conf ig) #ip weep web-cache 

2. Enter the (config-if) submode by telling WCCP which IP address to use. 

Router (conf ig) # int interface 

where interface is the adapter interface with an IP address. The prompt changes to 
configuration interface submode. 

3. Enable packet redirection on an outbound (Internet facing) interface. 

Router (conf ig-if) # ip weep web-cache redirect out 

4. Prevent packets received on an adapter interface from being checked for redirection 
and allow the use of Blue Coat bypass lists. 

Router (conf ig-if ) # ip weep redirect exclude in 

For more information on WCCP router configuration, see "Configuring a WCCP Version 2 
Service on the Router" on page 214. 
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To create an SG appliance WCCP configuration file and enable WCCP: 

1. Create a WCCP configuration file through either the SG appliance's CLI inline 
commands or through a text editor. Make sure that the home router you enter here is 
the home router that was named in the router's configuration. If you do have a 
mismatch, you must correct it before continuing. See "Identifying a Home Router/ 
Router ID Mismatch" on page 231. 

For more information on creating a configuration file, see "Creating an SG Appliance 
WCCP Configuration File" on page 220. 

If you used the inline commands, you have completed WCCP configuration for both 
the router and the SG appliance and you have enabled WCCP on the SG appliance. No 
further steps are needed. 

2. If you used a text editor, copy the file to an HTTP server accessible to the SG appliance. 

3. Enable WCCP and download the configuration file to the SG appliance. 

SGOS# (config) weep enable 

SGOS# (config) weep path http://205.66.255.10/files/wccp.txt 
SGOS# (config) load weep-settings 

Configuring a WCCP Version 2 Service on the Router 

Configuring a router requires that you work with two different types of configuration 
commands: 

□ Creating a service group (which uses global settings). 

□ Configuring the Internet-Connected Interface (which uses interface settings). 

Define service group settings before defining adapter interface settings. 

Setting up a Service Group 

Services are of two types: 

□ Well known services (web-cache for port 80 — HTTP — redirection) 

□ The web-cache service group is supported by both Cisco and Blue Coat. 

□ Dynamic services (which can be used for other services, such as FTP, RTSP redirection, 
and reverse proxy). 

□ Dynamic service uses identifiers ranging from 0-99 to name the service group. 

WCCP global settings allow you to name the service group and then define the 
characteristics for that service group. Even if you use the pre-defined Web-cache service 
group, you should: 

□ configure a multicast group address 

□ create and identify a redirection access list and associate it with a service group 

□ create and identify a cache bypass list and associate it with a service group 

□ create password authentication for messages sent by the service group to the router 
Syntax for configuring a service group (global settings): 

ip weep {web-cache | service-number } [group-address group_address] 

[redirect- list access-list] [group-list access-list] [password 
password] 
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where: 



web-cache 


Enables port 80 (HTTP) service. 


service -number 


The identification number of the cache service group being controlled by the router. Services 
are identified using a value from 0 to 99. The reverse-proxy service is indicated using the 
value 99, although any value can be used for reverse proxy. 


group -address 
groupaddress 


(Optional) If no redirect list is defined (the default), all traffic is redirected. The group address 
option directs the router to use a specified multicast IP address to coalesce the "I See You" 
responses to the "Here I Am" messages that it has received on this address. The group - 
address argument requires a multicast address used by the router to determine which cache 
engine receives redirected messages. The response is sent to the group address, as well. If no 
group address is defined (the default), all "Here I Am" messages are responded to with a 
unicast reply. 


redirect-list 

access-list 


(Optional) Directs the router to use an access list to control traffic redirected to the defined 
service group. The access-list parameter specifies either a number from 1 to 99 identifying a 
predefined standard or extended access list number, or a name (up to 64 characters long) 
identifying an existing standard or extended access list. The access list itself specifies which 
traffic can be redirected. 


group- list 
access-list 


(Optional) If no group list is defined (the default), all caches might participate in the service 
group. 

The group - list option directs the router to use an access list to determine which caches are 
allowed to participate in the service group. The access-list parameter specifies either a 
number from 1 to 99 identifying a predefined standard or extended access list number or a 
name (up to 64 characters long) identifying an existing standard or extended access list. The 
access list itself specifies which caches are permitted to participate in the service group. 


password 

password 


(Optional) By default, password authentication is not configured and authentication is 
disabled. 

The password option increases authentication security to messages received from the service 
group specified by the service-number. Messages that do not pass authentication are 
discarded. The password can be up to eight characters long. 

If you specify a password in the router configuration, you must also configure the same 
password separately on each cache. 



Naming a Service Group and Enabling WCCP 

WCCP version 2 is enabled when you name a WCCP service group. (Version 1 requires a 
specific enable command.) The service group can already exist, such as web-cache, or it 
could be a new group, such as 3 6. 

To name a service group and enable WCCP: 

From the router (config) mode, enter the following command: 

Router# (config) ip weep web-cache 

-or- 

Router# (config) ip weep 36 

Configuring a Global Multicast Group Address 

Benefits of using a multicast address include reduced WCCP protocol traffic and the 
ability to easily add and remove caches and routers from a service group without having 
to reconfigure all service group members. Multicast addresses fall within the range of 
224.0.0.0 to 239.255.255.255. 
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Use the following syntax to configure a global multicast group address for multicast cache 
discovery. 

ip weep {web-cache | service-number } [group-address group_address ] 

To configure a multicast address: 

From the router ( conf ig ) mode, name the group that uses the multicast address, provide 
the address, then tell the router which adapter interface is used: 

Router (conf ig) # ip weep 36 group-address 225.1.1.1 
Router (conf ig) # interface ethernet 0 
Router (conf ig-if) # end 

Creating a Redirection Access List and Associating it with a Service 
Group 

Redirection access lists can contain commands redirecting packets from one network or 
cache to another. The lists also can be used to determine which caches participate in which 
service groups. 

The two lists, although similar, have different purposes, and are applied to the router 
differently. The redirection lists are applied with the redirect-list option. The cache bypass 
lists are applied with the group-list argument. Both lists can be identified with either a 
name or a number. 

Use the following syntax to create a redirection access list. This is partial syntax for this 
command. Access lists are very complicated; refer to the Cisco Web site for complete 
syntax. 

access-list acl_ID [deny | permit] protocol { [ source_addr source_mask] 
[local_addr local_mask ] } 

where: 



acl ID 


Names the access list you are creating. You can use either a name or number. 


deny 


Indicates that you do not want to allow a packet to traverse the Cisco router. By default, the 
router firewall denies all inbound or outbound packets unless you specifically permit access. 


permit 


Selects a packet to traverse the PIX firewall. By default, the router firewall denies all inbound 
or outbound packets unless you specifically permit access. 


protocol 


Identifies, by name or number, an IP protocol. This parameter can be one of the keywords 
iemp, ip, tep, or udp, or an integer in the range 1 to 254 representing an IP protocol number. 
To match any Internet protocol, including ICMP, TCP, and UDP, use the keyword ip. 


source_addr 


Indicates the address of the network or host from which the packet is being sent. Use the 
keyword any as an abbreviation for an address of 0 . 0 . 0 . 0 . 


source_mask 


Specifies the netmask bits (mask) to be applied to source_addr, if the source address is for a 
network mask. Use the keyword any as an abbreviation for a mask of 0 . 0 . 0 . 0. 


local addr 


Indicates the address of the network or host local to the PIX firewall. The local addr is the 
address after NAT has been performed. Use the keyword host, followed by address, as an 
abbreviation for a mask of 255 . 255 . 255 . 255. 


local mask 


Specifies the netmask bits (mask) to be applied to local addr, if the local address is a 
network mask. Use the keyword host followed by address as an abbreviation for a mask of 
255.255.255.255. 
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To create a redirection access list or a cache bypass list: 

From the router (conf ig) prompt, name an access list and assign rules to it. 

Router (config) # access-list 100 deny ip any host 126 . 10 . 10.10 

Router (conf ig) # access-list 100 permit ip any any 

Router# 

□ The commands above gave the access list a name of 100. 

□ Denied packets from any protocol to be sent from any host on the 126.10.10.10 
network. 

□ Permitted packets from any protocol to be sent from any other network. 

To associate a redirection access list with a specific service group: 

1. Create a redirection access list. 

2. Associate the access list with a specified service group. 

ip weep (web-cache | service-number } [redirect-list access-list] 
Router (conf ig) # interface ethernet 0/0 

Router (conf ig-if) # ip weep web-cache redirect-list 100 

Router (conf ig-if) # end 
Router# 

To associate a cache bypass access list with a specific service group: 

1. Create a redirection access list, using the syntax discussed above. 

2. Associate the access list with a specified service group. 

ip weep (web-cache | service-number } [group-list access-list] 

Router (conf ig) # interface ethernet 0 

Router (conf ig-if ) # ip weep web-cache group-list 120 

Router (conf ig-if ) # end 

Router# 

Configuring the Internet-Connected Interface 

WCCP interface settings allow you to configure the Internet-connected adapter interface 
that redirects Web traffic to the content engine. 

Using the interface commands allows you to: 

□ Enable and prevent packet redirection 

□ Enable reception of multicast packets for service group member routers 

Syntax for configuring an Internet-connected adapter interface (interface settings): 

ip weep [{web-cache | service-number } redirect out | group- listen] 
redirect exclude in 



where: 



web -cache 


Enables the Web cache service group. 


servi ce -number 


The identification number of the cache service group being controlled by 
the router. Services are identified using a value from 0 to 99. The reverse- 
proxy service is indicated using the value 99. 


redirect out 


Enables packet redirection on an outbound (Internet facing) adapter 
interface. 
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group-listen 


On a router that is a member of a service group, enables the reception of 
pre-defined IP multicast packets. 


redirect 
exclude in 


Prevents packets received on an adapter interface from being checked for 
redirection. If the cache service-group is located on a separate router 
interface, the possibility exists that bypass filters could be enabled on the 
cache. 



Using Packet Redirection 

WCCP communication among the routers and the appliances can be done by either 
directly addressing protocol packets to each router's and cache's IP address (as illustrated 
in Figure C-l on page 212) or by sending these packets to a common multicast address as 
illustrated in Figure C-3, below: 




Figure C-3. A Version 2 Configuration Using Multicast Packet Redirection 



You can configure redirection on inbound or outbound interfaces. 



To configure redirection on the outbound interfaces: 

Use the following syntax to configure redirection on the outbound adapter interface. 

ip weep {web-cache | service-number } redirect out 
From the router (config) prompt, enter the following: 

Router (config) # interface ethernet 0 

Router (config-if) # ip weep web-cache redirect out 

Router (config- if ) # end 



To exclude packet redirection on an inbound adapter interface: 

Use the following command to prevent packets received on an adapter interface from 
being checked for redirection. 

ip weep redirect exclude in 

The following example shows how to exclude Blue Coat adapter interface (xx, in this 
case) and allow use of Blue Coat bypass lists: 

From the router (config) prompt, enter the following: 

Router (config) # int xx 

Router (config-if ) # ip weep redirect exclude in 

Router (config-if ) # end 
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Enabling Reception of Multicast Packets 

Benefits of using a multicast address include reduced WCCP protocol traffic and the 
ability to easily add and remove caches and routers from a service group without having 
to reconfigure all service group members. You (optionally) set up a multicast group 
address in "Configuring a Global Multicast Group Address". In the following procedure, 
you enable the reception of the pre-defined IP multicast packets to routers that are 
members of the group. 

Multicast addresses fall within the range 224.0.0.0 to 239.255.255.255. 

Use the following syntax to configure for multicast discovery of the cache(s). 

ip weep {web-cache | service-number } group- listen 

The following example configures the router to use the WCCP 36 service group to redirect 
port 80 destination traffic. WCCP protocol traffic uses multicast address 225 . 1 . 1 . 1 . 
Adapter interface "Ethernet 0" is used to receive the multicast WCCP traffic. 

Router (config) # ip weep 36 group-address 225.1.1.1 

Router (config) # interface ethernet 0 

Router (config-if) # ip weep web-cache group-listen 

Router (config- if ) # end 

Saving and Viewing Changes 

Once you have made all the changes, you must permanently save them to disk. If not, the 
changes are lost at the next reboot of the router. 

To save router configuration: 

Router# write memory 

To display all current WCCP configuration settings: 

Use the following syntax to verify the settings in the new router configuration and to 
ensure that the appropriate cache engines are visible to the router. 

show ip weep {web-cache | service -number} [view | detail] 

where 



view 


(Optional) Lists all members of the identified service group and whether they have 
been detected. 


detail 


(Optional) Displays IP and protocol version information about the router. Displays IP, 
protocol version, state, initial and assigned hash, hash allotment, redirected packet, 
and connection time information about the associated cache engine (SG appliance). 



For example: 

Router# show ip weep web-cache view 

Global WCCP Information: 

Service Name: web-cache: 

Number of Cache Engines : 1 

Number of Routers : 1 

Total Packets Redirected : 186 

Redirect Access-list : 120 

Total Packets Denied Redirect: 57 

Total Packets Unassigned : -none- 

Group Access-list : 0 

Total Messaged Denied to Group : 0 

Total Authentication Failures : 0 
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WCCP Router Informed of : 

86 . 135 . 77.10 
186 . 135 . 77.20 

WCCP Cache Engines Visible: 

186 . 135 . 77 . 11 

186 . 135 . 77 . 12 

WCCP Cache Engines Not Visible: 

-none- 

Creating an SG Appliance WCCP Configuration File 

Once you have the router global and adapter interface settings complete, you must create 
a WCCP configuration file for the SG appliance. These configurations should include the 
following: 

□ Identify the service group. 

□ Identify the queuing priorities for all defined service groups. 

□ Identify the protocol. 

□ Load balancing caches in a service group. 

□ Identify ports. 

□ Identify the home router as defined in the router configuration. 

□ Identify the packet forwarding method. 

Understanding Packet Forwarding 

By default, Cisco's GRE encapsulation (Generic Routing Encapsulation) is used to 
forward packets from the WCCP router to the caches. If you have a version 2 WCCP 
router, you can alternatively use Layer 2 (L2) rewrites to forward packets, which is faster 
than GRE and saves network bandwidth. 

Using GRE, redirected packets are encapsulated in a new IP packet with a GRE header. 

Using L2, redirected packets are not encapsulated; the MAC address of the target cache 
replaces the packet's destination MAC address. This different way of directing packets 
saves you the overhead of creating the GRE packet at the router and decoding it at the 
cache. Also, it saves network bandwidth that would otherwise be consumed by the GRE 
header. 

If you want to continue using GRE, you need not change any settings. To use L2 packet 
redirection, you must add the forwarding option to the SG configuration file. 

If WCCP version 2 is supported, the router sends out a list of forwarding mechanisms 
supported by the router in the first wccp2_i_see_you message. The cache responds with a 
wccp2_here_i_am message. If the router does not send the list, the cache aborts its 
attempt to join the WCCP service group. If the method of forwarding mechanism is not 
supported by the router, the WCCP2 messages from the cache are ignored. 

Caveats for using L2 redirection: 

□ You must use WCCP version 2. 

□ If a cache is not connected directly to a router, the router does allow the cache to 
negotiate the rewrite method. 
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□ The same rewrite method must be used for both packet forwarding and packet return. 

Understanding Cache Load Balancing 

If you use WCCP version 2, you can balance the load on the caches in a service group. 
When a router receives an IP packet for redirection, it hashes fields within the packet to 
yield an index within the hash table. The packet then is forwarded to the owner SG 
appliance for servicing. The proportion of redirection hash table assigned to each SG 
appliance can be altered to provide a form of load balancing between caches in a service 
group. 

A hash table is configured by a dynamically elected SG appliance participating in a service 
group, enabling the simultaneous interception of multiple protocols on multiple ports. 
You can configure up to 100 dynamic or standard service groups plus standard service 
groups. A single service can intercept up to eight port numbers. 

Each element in this 256-entry hash table refers to an active SG appliance within the service 
group. By default, each SG appliance is assigned roughly an even percentage of the 256- 
element redirection hash table. Multiple network cards within an SG appliance can 
participate in the same service group. To the routers and other caches, each adapter 
interface appears as a unique cache. Using this strategy, redirected traffic can be better 
distributed among network interfaces in a cache. 

Using Figure C-4, below, all caches would be assigned 1 /m of the redirection hash table, 
but since Cache 2 and Cache 3 are physically located within the same appliance, that 
appliance is actually assigned 2/m of the redirection hash table. 
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Figure C-4. A Version 2 Configuration Using Multicast Packet Redirection to Multiple Routers, 
Multiple Caches, and a Service Group 

Assigning Percentages 

You can override the default of each SG appliance being assigned roughly an even 
percentage; the relative distribution of the redirection hash table can be specified for each 
cache. Multiple hash-distributions are supported. Also, all, none, or part of a source and/ 
or destination IP address or port number can be used in the hash. Each SG appliance can be 
assigned a primary-hash-weight value to determine the proportion of the 256-element 
hash table to be assigned. 

If all caches are configured with a 0 primary-hash-weight value (the default) then each SG 
appliance is assigned an equal proportion of the redirection hash table. However, if any SG 
appliance is configured with a non-zero primary-hash-weight, each SG appliance is 
assigned a relative proportion of the table. 
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For instance, consider a configuration with five caches that use a primary-hash-weight 
defined as {25, 200, 0, 50, 25}. The total requested weight value is 25+200+0+50+25=300 
and, therefore, the proportion of the hash table assigned to each SG appliance is 25/300, 
200/300, 0/300, 50/300, and 25/300. 

Because one cache did not specify a non-zero primary-hash-weight, that cache is assigned 
any elements within the redirection hash table and, therefore, does not receive any 
redirected traffic. Also, the hash weight can be specified for each caching member within a 
SG appliance. In Figure C-4, Cache 2 and Cache 3 can be assigned different weight values. 

Alternate Hash Table 

In some cases, a Web site becomes an Internet hot spot, receiving a disproportional number 
of client traffic relative to other sites. This situation can cause a larger request load on a 
specific SG appliance because the hash element associated with the popular site receives 
more activity than other hash elements. 

To balance the redirection traffic load among the caches, a service group can be configured 
to use an alternate hash function when the number of GRE packets forwarded to the cache 
exceeds a certain number. (If you use L2 forwarding, the SG appliance counts MAC 
addresses.) Therefore, when a router receives an IP packet that hashes to an element 
flagged as a hot spot, the alternate hash function is computed. The SG appliance specified 
by the new index in the redirection hash table receives the redirected packet. 

Each SG appliance can dynamically determine a hot spot within its assigned portion of the 
redirection hash table. 

Alternate hash tables are only used for dynamic service groups that specify alternate-hash 
flags within their service-flags. The default Web-cache service group cannot use an 
alternate hash table. Instead, a comparable dynamic service group must be created. 

To use hot spot detection, the SG appliance's WCCP configuration file must specify: 
service-flags source- ip-hash 

service- flags destination-port -alternate -hash 

Creating a Configuration File 

An example of a file using a dynamic service, as opposed to the default Web-cache service, 
is shown below: 

If using the default Web-cache service, the service group settings priority, protocol, 
service flags, and ports are not used. 

weep enable 
weep version 2 
service-group 9 
f orwarding-type L2 
priority 1 
protocol 6 

service- flags destination- ip -hash 
service-flags ports-def ined 
ports 80 21 1755 554 80 80 80 80 
interface 6 

home -router 10.16.18.2 
end 

You can create a configuration file customized for the environment two ways: CLI inline 
commands or through a text file. In either case, the configuration file must include the 
information required by the commands below. 

Syntax to create a customized configuration file: 
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service-group {web-cache | service -number } 

[priority priority-number] 

[protocol protocol -number] 

[service- flags hash-bit- identifier] 

[ports portl ... port8] 

home-router [ip-address | domain-name] 
interface [interface-number] 

[password string] 

[primary-hash-weight interface-number value] 
f orwarding-type [GRE | L2] 

Using Optional Negation Syntax, you can create an alternative WCCP configuration file 
using these negative commands; this is especially helpful when testing and debugging. 
This functionality enables you to change some of the configuration settings without 
altering or reloading the main configuration file. 

[no] service-group {web-cache | service -number} 

[priority priority-number ] 

[protocol protocol -number] 

[no] service-flags hash-bit-identifier 
[ports portl ...port8] 

home-router [ ip-address | domain-name] 

[multicast-ttl [ttl_value]] 

[no] interface [ interface-number ] 

[password string | no password] 

[primary-hash-weight interface-number value] 

where: 



web -cache 


Enables the Web cache service group. If using the Web-cache service group for 
WCCP, the dynamic service group settings (priority, protocol, service 
flags, and ports) are not applicable. 


service -number 


The identification number of the dynamic service group being controlled by the 
router. Services are identified using a value from 0 to 99. The reverse-proxy service 
is indicated using the value 99. 


priority-number 


(Applies to a dynamic service group only. A dynamic service group is one 
identified by a service number.) Establishes queuing priorities for all defined 
service groups, based on a priority number from 0 through 255, inclusive. 


protocol -number 


(Applies to a dynamic service group only. A dynamic service group is one 
identified by a service number . ) Number of an Internet protocol. Protocol - 
number must be an integer in the range 0 through 255, inclusive, representing an 
IP protocol number. 


hash-bi t- identifier 


(Applies to a dynamic service group only. A dynamic service group is one 
identified by a service number.) Sets the hash index, for load balancing purposes. 
The key associated with the hash-bit - identifier you specify is hashed to 
produce the primary redirection hash table index. For instance, if only the 
destination- ip-hash flag is set, then the packet destination IP address is used 
to determine the index. The index is constructed by starting with an initial value of 
zero and then computing an exclusive OR (XOR) of the fields specified in the hash- 
bit identifier. 

If alternative hashing has been enabled, any alternate hash flags are processed in 
the same way and produce a secondary redirection hash table index. Alternate 
hash flags end with the suffix "-alternate-hash." 

For more information using the hashing table, see "Understanding Cache Load 
Balancing" on page 221. 
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source -ip -hash 
{hash-bit -identifier) 


Sets the source IP bit definition within the redirection hash table index. 


destination- ip -hash 
{hash-bit -identifier) 


Sets the source IP bit definition within the redirection hash table index. 


source -port - hash 
{hash-bit -identifier) 


Sets the source port bit definition within the redirection hash table index. 


destinat ion -port -hash 
{hash-bit -identifier) 


Sets the destination port bit definition within the redirection hash table index. 


ports-def ined 
{hash-bit- identifier) 


Sets the port bit definition within the redirection hash table index. 


ports -source 
{ hash -bit- identifier ) 


Sets the source port bit definition within the redirection hash table index. 


source-ip-alternate- 

hash 

{hash -bit -identifier) 


Sets the alternate source IP bit definition within the redirection hash table index. 


des t inat ion- ip- 
alt e mate -hash 
{hash-bit -identifier) 


Sets the alternate destination IP bit definition within the redirection hash table 
index. 


source-port- 
alternate -hash 

{hash-bit -identifier) 


The alternate source port bit definition within the redirection hash table index. 


destination-port- 
alte mate -hash 
{hash -bit- identifier) 


Sets the alternate destination port bit definition within the redirection hash table 
index. 


multicast-ttl 


Sets the multicast TTL value per WCCP service group. The value must be set 
between 1 and 255. 

If the multicast TTL value is not set, the default value is 1. If the home-router 
address is not multicast, this command is non-operational. 


portl...port8 


(Applies to a dynamic service group only. A dynamic service group is one 
identified by a service number.) A zero-terminated list of TCP port identifiers. 

Note that this must be a list of exactly eight ports. 

If the service-flags ports-defined flag is set, packets are matched against the set of 
ports supplied. If the service-flags ports-source flag is set, the ports are 
assumed to be source ports. Otherwise, the ports are assumed to be destination 
ports. 


ip-address 


Indicates the IP address of your network’s home router. For version 2, ip - 
address can be a multicast address. (Multicast addresses are in the range 
224 . 0 . 0 . 0 to 239 . 255 . 255 . 255 , inclusive.) 

In version 2, multiple IP addresses can be specified for unicast addressing. For 
multicast addresses, only one IP address can be specified per service group. 

If you choose to specify the home router IP address, it is important that the actual 
home router IP address and the home router IP address specified in this SG 
configuration file match. If you do not already know the IP address of the home 
router, you can easily determine it from the router CLI by using the show ip 
weep command. 
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domain-name 


Specifies the domain name of your network's home router. Domain-name must be 
a valid domain name string that successfully resolves on DNS lookup. 


interface -number 


Specifies the adapter interface number for the service group. You cannot use a 
colon (0 : 0 or 0 : 1, for example). 


string 


(Applies to a dynamic service group only. A dynamic service group is one 
identified by a service number.) String can be at least one, and not more than eight, 
alphanumeric characters long. 

The password string specified here must match the password string declared for 
the router. 


interface -number 


(When used with the hash identifiers) Specifies the adapter interface to which the 
weight factor is applied to alter the distribution of the primary hash table. 


value 


Specifies the weight factor value (0 through 255) that is applied to the adapter 
interface specified to alter the distribution of the primary hash table. 


forwarding- type 
[GRE | L2 ] 


Switches between GRE encapsulation (the default) and L2 MAC address rewrite 
for forwarding packets. If this command is not present, GRE encapsulation is used. 



You can create a configuration file customized for the environment through the CLI inline 
commands or through a text file. The CLI inline commands enable WCCP on the SG 
appliance immediately; the drawback is that if any information changes, you must re- 
create the whole file using the inline command. With a text file, if any information 
changes, you can change the individual line; the drawback is that you must download the 
file again from an HTTP server to the SG appliance. 

To use CLI commands to create a configuration file, continue with the next procedure. To 
use a text editor to create a configuration file, continue with "Creating a Configuration 
File using a Text File" on page 226. 

Creating a Configuration File using CLI Inline Commands 

For examples of various types of WCCP configurations, see "Examples" on page 226. 

If you choose to configure through the CLI and the ini ine command, refer to the example 
below: 

SGOS# configure terminal 

SGOS# (config) inline weep eof 

where eof marks the beginning and end of the inline commands. 

For example: 

SGOS# (config) inline weep eof 
weep enable 
weep version 2 
service-group 9 
f orwarding-type L2 
priority 1 
protocol 6 

service- flags destination- ip -hash 
service- flags ports-def ined 
ports 80 21 1755 554 80 80 80 80 
interface 6 

home -router 10.16.18.2 

end 

eof 
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You created a WCCP configuration file and enabled WCCP on the SG appliance. WCCP 
setup is complete. 

Creating a Configuration File using a Text File 

If you create a configuration file using a text editor, assign the file the extension . txt. The 
following are SG configuration file rules: 

□ Only one command (and any associated parameters) is permitted, per line. 

□ Comments must begin with a semicolon ( ; ) or a pound sign (#). 

□ Comments can begin in any column; however, all characters from the beginning of the 
comment to the end of the line are considered part of the comment and, therefore, are 
ignored. 

For examples of various types of WCCP configurations, see "Examples" on page 226. 

To create a configuration file using a text editor and load the file on an SG 
appliance: 

1. Open a text editor. 

2. Using the commands described in "Syntax to create a customized configuration file:" 
on page 222, enter the arguments you need. 

3. Copy the configuration file to an HTTP server so that it can be downloaded to the SG 
appliance. 

4. Enable WCCP and download the WCCP configuration file using the following syntax: 

weep {enable | disable | no} [path config-file-url ] | [version version- 

number] 

where: 



enable 


Enables WCCP on the SG appliance. 


disable 


Disables WCCP on the SG appliance. 


no 


Indicates that you want to clear the current WCCP configuration settings. 


config-file-url 


Specifies the SG WCCP configuration file or alternate configuration file. 


vers ion -number 


Indicates the version of WCCP that your router is configured to use. If 
version version-number is omitted, it is assumed to be 2. 



For example: 



SGOS# (config) 
SGOS# (config) 
SGOS# (config) 



weep enable 

weep path http://205.66.255.10/files/wccp.txt 
load weep-settings 



Examples 

This section provides detailed examples of both the router and SG configurations for: 

□ Standard HTTP redirection 

□ Standard HTTP redirection and a multicast address 

□ Standard HTTP redirection and a security password 

□ Standard transparent FTP 
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□ A service group and alternate hashing 

For information and examples about using WCCP, refer to http:/ / www.cisco.com/ 
univercd/ cc/ td/ doc/product/ software/ iosl21/ 121cgcr/ fun_r/ frprt3/ frd3005.htm. 

Displaying the Router’s Known Caches 

Use the router show command to display information about the appliances that are known 
to the router. 

Router# show ip weep web-caches 

WCCP Web-Cache information: 

IP Address : 192 . 168 . 51 . 102 
Protocol Version: 0.3 
State : Usable 
Initial Hash 

Info : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
Assigned Hash: 

Info : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
Hash Allotment: 256 (100.00%) 

Packets Redirected: 0 
Connect Time : 00 : 00 : 31 
Router# exit 

Standard HTTP Redirection 

The web-cache service group enables HTTP traffic redirection on port 80. 

Router Configuration 

The following example enables standard HTTP traffic redirection on a WCCP version 2- 
capable Cisco router. 

Router (config) # ip weep web-cache 

Router (config) # interface ethernet 0/0 

Router (config-if) # ip weep web-cache redirect out 

Router (config-if) # end 

SG Configuration 

To enable the Web-cache service group within the SG appliance, the following 
configuration file could be loaded. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified here. 

service-group web-cache 

# Specify the address for the router. 

home -router 90.0.0.90 

# Network interface 0 will participate. 

interface 0 

end 
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Standard HTTP Redirection and a Multicast Address 

Configuring a multicast address on a WCCP-capable router provides reduced WCCP 
protocol traffic and the ability to easily add and remove caches and routers from a service 
group without having to reconfigure all service group members. 

Router Configuration 

The following example enables the standard HTTP traffic redirection on a WCCP 
version 2-capable Cisco router. In this case, WCCP protocol traffic is directed to the 
multicast address 226.1.1.1. 

Router (config) # ip weep web-cache group-address 226.1.1.1 
Router (config) # interface ethernet 0/0 
Router (config-if) # ip weep web-cache group-listen 
Router (config-if) # ip weep web-cache redirect out 

Router (config-if ) # end 

SG Configuration 

To enable the standard Web-cache service group within the SG appliance, the following 
configuration file should be loaded. In this example, both network interfaces 0 and l 
participate within the service group. Both interfaces send and receive WCCP protocol 
packets by way of the multicast address. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified here. 

service-group web-cache 

# Specify the multicast address. 

home -router 239.192.5.3 

# Network interface 0 will participate. 

interface 0 

# Network interface 1 will also participate. 

interface 1 
end 

Standard HTTP Redirection Using a Security Password 

A simple eight-character password is configured within the router. This password must 
match the password configured within the SG appliance. 

Router Configuration 

The following example enables standard HTTP traffic redirection on a WCCP version 2- 
capable Cisco router. 

Router (config) # ip weep web-cache password 29gy8c2 

Router (config) # interface ethernet 0 

Router (config-if ) # ip weep web-cache redirect out 

Router (config-if ) # end 

SG Configuration 

To enable the standard WCCP version 2 service group within the SG appliance, the 
following configuration file could be loaded. 
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# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2 " command could be specified 

# here . 

service-group web-cache 

# Specify the address for the router. 

home -router 90.0.0.90 

# Network interface 0 will participate. 

interface 0 
password 29gy8c2 
end 

Standard Transparent FTP 

In WCCP version 1, only HTTP traffic on port 80 could be redirected. In WCCP version 2, 
you can create a numbered service group that redirects other protocols on other ports. 

You set the service group on the router, and tell the SG appliance which ports should be 
redirected. 

Router Configuration 

In this configuration, you create a new service group that you are dedicating to FTP 
redirects. 

# Enables the service group that redirects ports besides 80. 

Router (config) # ip weep 10 

# Enables a service group that allows user-defined 

# ports to be redirected. 

Router (config) # int eO 

Router (config-if) # ip weep 10 redirect out 

SG Configuration 

In this configuration, you take the service group created by the router and assign the 
characteristics to the group. 

SGOS# (config) inline weep eof 

weep enable 

service-group 10 

interface 0 

home-router 10 . 1 . 1.1 

protocol 6 

priority 1 

service- flags ports-def ined 
service- flags destination-port-hash 
ports 20 21 80 80 80 80 80 80 
eof 

Reverse Proxy Service Group 

This service group redirects IP packets for TCP destination port 80 traffic by hashing the 
source IP address. 

Router Configuration 

The following example enables the special SG service group on a WCCP-capable router. 
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Router (config) # ip weep 99 
Router (config) # interface ethernet 0/0 
Router (config-if) # ip weep 99 redirect out 
Router (config-if) # end 

SG Configuration 

To configure the special SG service group on the appliance, a dynamic service group must 
be created as illustrated by the following example. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified here. 

# Service Group 99 is specially identified within the router 

# as representing the ProxySG Appliance service. 

service-group 99 

# Specify the address for the router. 

home -router 90.0.0.90 

# Network interface 0 will participate. 

interface 0 

# Specify the TCP protocol. 

protocol 6 

# The hash should be based on the source IP address . 

service-flags source- ip-hash 
end 

Service Group with Alternate Hashing 

You can create a special service group on a WCCP-capable router that uses alternate 
hashing when hot spots are detected. This service group redirects IP packets by hashing 
the source IP address. 

Router Configuration 

In this configuration, you create a new service group that you are dedicating to Website 
hot spots. 

Router (config) # ip weep 5 
Router (config) # interface ethernet 0/0 
Router (config-if ) # ip weep 5 redirect out 
Router (config-if ) # end 

SG Configuration 

To configure this special service group on the SG appliance, a dynamic service group must 
be created. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified here. 

# Service Group 5 is created to redirect standard HTTP 

# traffic and use an alternate hash function based on the 

# source IP address, if necessary, 
service-group 5 

# Specify the address for router 1 . 

home - router 90.0.0.90 
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# Specify the address for router 2 . 

home -router 90.0.1.5 

# Network interface 0 will participate. 

interface 0 

# Specify the TCP protocol . 

protocol 6 

# The following two flags specify that a hash function based 

# on the destination IP address should be applied first. If 

# a hot-spot is detected, then an alternate hash 

# function using the source IP address should be used, 
service- flags destination- ip -hash 

service- flags source- ip -alternate -hash 
end 

Troubleshooting: Home Router 

If you install WCCP settings and then later upgrade the Cisco IOS software or change 
network configuration by adding a device with a higher IP address, the change might 
result in a different home router IP assignment. WCCP might or might not work under 
these conditions, and performance might decrease. If you upgrade the router software or 
change the network configuration, verify that the actual home router IP address and home 
router IP address in the WCCP configuration match. 

To verify the home router IP address matches the home router IP address listed in 
the WCCP configuration: 

1. From the router CLI, view the WCCP configuration: 

Router# (config) show ip weep 

The home router information appears, similar to the example below: 

Global WCCP information: 

Router information: 

Home router Identifier : 195 . 200 . 10 . 23 0 
Protocol Version: 2.0 

2. From the Blue Coat SG appliance, verify that the home router IP address specified in 
the SG WCCP configuration file is the same as the actual home router IP address 
discovered through the router CLI command. The following is an SG WCCP 
configuration file showing the same home router IP as in the example above: 

SGOS# show weep config 

; WCCP Settings 
/Version 1.3 
weep enable 
weep version 2 
service-group web-cache 
interface 1 

home -router 195.200.10.230 
end 

In this case, the two home router identifiers match. 

Identifying a Home Router/Router ID Mismatch 

The following is some helpful information for resolving a home-router /Router ID mis- 
match that results in the router crashing the SG appliance. This situation can occur when 
the router interface is set to a higher IP address than the home-router and WCCP 
messages show w/bad rcv_id. 



231 



Volume 6: Advanced Networking 



WCCP version 1 does not care what home router the cache had configured. So if you 
upgrade from WCCP version 1 to WCCP version 2, the router might pick a different IP 
address than was configured as a home router in the cache. 

This means that a mismatch can occur after an upgrade. 



SG Configuration 

Use the show weep statistics command to identify the configured home router and the 
highest router IP. 

SGOS# (config) show weep statistics 



Service Group ident . 
1755,554,20,21, 80,80 
Home Routers : 

Hotspots announced 
Assignment state 
Designated Cache : 

Announcement key # 
Cache view change # 
Router View Changed 
Recent hit count 
Primary hit count 
Alternate hit count 
Instance IP address : 
Sequence info 
Query response info: 
Active 

Primary hash weight 
Hotspot information 
Total assign weight 
Router IP address : 
Router 

Receive # 

Change # 

Activation time 
Last I-See-You time 
Active caches 
Assignment key 
Router state 
Cache 
Active 



80,80 

.•10.2.3, 

: 0 



: 512 , 1 , 9 , 1,6,18, 



224 <<========Conf igured Home Router IP 



10 . 



: idle 

.228 <<= 



=Blue Coat IP 



: 13 



10.2.3 



<< 
0 
0 
0 
0 
228 



= === # times cache view changed 



<<=======Blue Coat IP 



: 10 .2 .3 . 231, 636 



1 
0 

0 , 0 , 0 , 0 
0 

10.2.3.231 <<=======Router ID/Highest IP on 



636 

4 

Wed, Jan 30 2002 
Wed, Jan 30 2002 
: 10.2.3.228 
:10.2.3.228,2 
: active 

: 10 .2 .3 . 228 , L, D 
: 1 



00:17:58 UTC 
01:08:58 UTC 



Notice that . 23 1 is highest IP on router and is automatically selected as the home router, 
even though . 224 is the configured home router IP. 

You can also use the show weep configuration command if you already know the 
highest IP and just want to know what the SG appliance identifies as the home-router. 

SGOS# (config) show weep configuration 

; WCCP Settings 
/Version 1.3 
weep enable 
weep version 2 
service-group 9 
interface 0 

home -router 10.2.3.224 
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protocol 6 
priority 1 

service-flags ports-def ined 
service- flags destination- ip -hash 
ports 1755 554 20 21 80 80 80 80 

Router Configuration 

The configuration below reveals that two interfaces are active on the router, and that one 
of the IP addresses is higher than the home router configured in the SG configuration file. 
The higher IP address takes over duties as the home router, causing a mismatch between 
the router and the SG appliance. 

Router# show conf 

Using 689 out of 129016 bytes 

version 12 . 1 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
hostname NachoL3 

enable secret 5 $l$r6nJ$dr58AZ . ZDg6RKA6MYeGRb . 
enable password nacho 
ip subnet -zero 
no ip routing 
ip weep 9 

interface FastEthernet0/0 
ip address 10.2.3.224 255.255.255.0 

ip weep 9 redirect out 
no ip route -cache 
no ip mroute- cache 
speed 100 
half -duplex 

i 

interface FastEthernetO/1 

ip address 10.2.3.231 255.255.255.0 

no ip route -cache 
no ip mroute -cache 
speed 100 
half -duplex 

Correcting a Home Router Mismatch 

The home router must have the same IP address on both the router and the SG appliance. 
Every time a higher IP address is introduced to the router, the higher address becomes the 
home router. 

On a WCCP router, the Router Identifier parameter is dynamically assigned. It cannot 
be manually configured. 

To set the correct home router IP address on the SG appliance: 

You cannot edit a WCCP configuration file created by the SGOS inline commands. You 
must recreate the configuration file. For more information on creating a WCCP 
configuration file using CLI commands on an SG appliance, see "Creating a Configuration 
File using CLI Inline Commands" on page 225. 

If you created a text file and downloaded it, you can edit the file and then download it 
again to the SG appliance. For more information for editing the WCCP text file and 
downloading it, see "Creating a Configuration File using a Text File" on page 226. 
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Tips 

If you use IP spoofing with WCCP, do the following for best results: 

□ The ip weep redirect exclude in command should be applied to the adapter to 
which the SG appliance is attached. 

□ For L2 forwarding, the SG appliance should be directly connected to the router 
interface. 
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